diff options
Diffstat (limited to 'doc/rfc/rfc9514.txt')
| -rw-r--r-- | doc/rfc/rfc9514.txt | 1155 |
1 files changed, 1155 insertions, 0 deletions
diff --git a/doc/rfc/rfc9514.txt b/doc/rfc/rfc9514.txt new file mode 100644 index 0000000..c926b3b --- /dev/null +++ b/doc/rfc/rfc9514.txt @@ -0,0 +1,1155 @@ + + + + +Internet Engineering Task Force (IETF) G. Dawra +Request for Comments: 9514 LinkedIn +Category: Standards Track C. Filsfils +ISSN: 2070-1721 K. Talaulikar, Ed. + Cisco Systems + M. Chen + Huawei + D. Bernier + Bell Canada + B. Decraene + Orange + December 2023 + + + Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment + Routing over IPv6 (SRv6) + +Abstract + + 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 + https://www.rfc-editor.org/info/rfc9514. + +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 + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + Trust Legal Provisions and are provided without warranty as described + in the Revised BSD License. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. BGP-LS Extensions for SRv6 + 3. SRv6 Node Attributes + 3.1. SRv6 Capabilities TLV + 3.2. SRv6 Node MSD Types + 4. SRv6 Link Attributes + 4.1. SRv6 End.X SID TLV + 4.2. SRv6 LAN End.X SID TLV + 4.3. SRv6 Link MSD Types + 5. SRv6 Prefix Attributes + 5.1. SRv6 Locator TLV + 6. SRv6 SID NLRI + 6.1. SRv6 SID Information TLV + 7. SRv6 SID Attributes + 7.1. SRv6 Endpoint Behavior TLV + 7.2. SRv6 BGP PeerNode SID TLV + 8. SRv6 SID Structure TLV + 9. IANA Considerations + 9.1. BGP-LS NLRI Types + 9.2. BGP-LS NLRI and Attribute TLVs + 9.3. SRv6 BGP EPE SID Flags + 10. Manageability Considerations + 11. Security Considerations + 12. References + 12.1. Normative References + 12.2. Informative References + Appendix A. Differences with BGP-EPE for SR-MPLS + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + SRv6 refers to Segment Routing instantiated on the IPv6 data plane + [RFC8402]. An SRv6 segment is often referred to by its SRv6 Segment + Identifier (SID). + + The network programming paradigm [RFC8986] 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 + [RFC9352] [RFC9513]. 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 [RFC9085] for the MPLS data plane instantiation (SR- + MPLS) and in [RFC9086] 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 [RFC7752]. + + 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). + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. BGP-LS Extensions for SRv6 + + BGP-LS [RFC7752] 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 + [RFC9352] or OSPFv3 [RFC9513] 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 (Section 3.1). + + * Maximum SID Depth (MSD) types introduced for SRv6 are advertised + (Section 3.2) using the Node MSD TLV specified in [RFC8814]. + + * Algorithm support for SRv6 is advertised via the SR-Algorithm TLV + specified in [RFC9085]. + + 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 [RFC8402] is advertised via the SRv6 End.X SID TLV + introduced in this document (Section 4.1). + + * The SRv6 SID of the IGP Adjacency SID to a non-Designated Router + (DR) or non-Designated Intermediate System (DIS) [RFC8402] is + advertised via the SRv6 LAN End.X SID TLV introduced in this + document (Section 4.2). + + * MSD types introduced for SRv6 are advertised (Section 4.3) using + the Link MSD TLV specified in [RFC8814]. + + 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 (Section 5.1). + + * The attributes of the SRv6 Locator are advertised via the Prefix + Attribute Flags TLV specified in [RFC9085]. + + The SRv6 SIDs associated with the node are advertised using the BGP- + LS SRv6 SID NLRI introduced in this document (Section 6). 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 (Section 7.1). + + * The BGP EPE Peer Node context for a PeerNode SID and the Peer Set + context for a PeerSet SID [RFC8402] are advertised via the SRv6 + BGP PeerNode SID TLV (Section 7.2). + + 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 [RFC7752]. + +3. 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. + +3.1. 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 [RFC9352] and the OSPFv3 SRv6 Capabilities TLV + [RFC9513] 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: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: SRv6 Capabilities TLV Format + + where: + + Type: 1038 + + Length: 4 + + Flags: 2-octet field. The flags are copied from the IS-IS SRv6 + Capabilities sub-TLV (Section 2 of [RFC9352]) or from the OSPFv3 + SRv6 Capabilities TLV (Section 2 of [RFC9513]) 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. + +3.2. SRv6 Node MSD Types + + The Node MSD TLV [RFC8814] of the BGP-LS Attribute of the Node NLRI + is also used to advertise the limits and the Segment Routing Header + (SRH) [RFC8754] operations supported by the SRv6-capable node. The + SRv6 MSD types specified in Section 4 of [RFC9352] 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 + [RFC9352]. + + 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 [RFC8814]. + +4. 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. + +4.1. 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 (Section 8.1 of + [RFC9352]) or the OSPFv3 SRv6 End.X SID sub-TLV (Section 9.1 of + [RFC9513]) 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 [RFC9085]. + + 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 + [RFC9086]. 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) [RFC8986] 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: + + 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) . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: SRv6 End.X SID TLV Format + + 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 of flags. The flags are copied from the IS-IS SRv6 + End.X SID sub-TLV (Section 8.1 of [RFC9352]) or the OSPFv3 SRv6 + End.X SID sub-TLV (Section 9.1 of [RFC9513]) 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 Section 7.2. + + 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 [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. This document defines one + in Section 8. + +4.2. 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 (Section 8.2 of [RFC9352]) or the OSPFv3 SRv6 + LAN End.X SID sub-TLV (Section 9.2 of [RFC9513]) 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) [RFC8986] 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: + + 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) . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: SRv6 LAN End.X SID TLV Format + + 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 Section 10.2 of [RFC8986]. + + Flags: 1 octet of flags. The flags are copied from the IS-IS SRv6 + LAN End.X SID sub-TLV (Section 8.2 of [RFC9352]) or the OSPFv3 + SRv6 LAN End.X SID sub-TLV (Section 9.2 of [RFC9513]) 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 Section 8. + +4.3. SRv6 Link MSD Types + + The Link MSD TLV [RFC8814] 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 Section 4 of [RFC9352] 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 [RFC9352]. + + 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 [RFC8814]. + +5. 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. + +5.1. SRv6 Locator TLV + + As specified in [RFC8986], 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 (Section 7.1 of [RFC9352]) or the OSPFv3 SRv6 + Locator TLV (Section 7.1 of [RFC9513]) 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 + [RFC7752] 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: + + 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) . . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: SRv6 Locator TLV Format + + where: + + Type: 1162 + + Length: variable + + Flags: 1 octet of flags. The flags are copied from the IS-IS SRv6 + Locator TLV (Section 7.1 of [RFC9352]) or the OSPFv3 SRv6 Locator + TLV (Section 7.1 of [RFC9513]) 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 (Section 7.1 of [RFC9352]) + or the OSPFv3 SRv6 Locator TLV (Section 7.1 of [RFC9513]) 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. + +6. SRv6 SID NLRI + + The Link-State NLRI defined in [RFC7752] 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: + + 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) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: SRv6 SID NLRI Format + + where: + + Protocol-ID: 1-octet field that specifies the information source + protocol [RFC7752]. + + Identifier: 8-octet value as defined in [RFC7752]. + + Local Node Descriptors TLV: Set of Node Descriptor TLVs for the + local node as defined in [RFC7752] for IGPs, the Direct Protocol- + ID, and the Static configuration Protocol-ID or as defined in + [RFC9086] for BGP. + + SRv6 SID Descriptors: Set of SRv6 SID Descriptor TLVs. This field + MUST contain a single SRv6 SID Information TLV (Section 6.1) and + MAY contain the Multi-Topology Identifier TLV [RFC7752]. + + New TLVs for advertisement within the BGP-LS Attribute [RFC7752] are + defined in Section 7 to carry the attributes of an SRv6 SID. + +6.1. 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 (Section 7.2 of + [RFC9352]) or the OSPFv3 SRv6 End SID sub-TLV (Section 8 of + [RFC9513]) in the case of IS-IS or OSPFv3, respectively. + + The TLV carries the SRv6 SIDs corresponding to the BGP PeerNode and + PeerSet SIDs [RFC8402] when SRv6 BGP EPE functionality is enabled in + BGP. + + The TLV has the following 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 ...) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: SRv6 SID Information TLV Format + + where: + + Type: 518 + + Length: 16 + + SID: 16-octet field. This field encodes the advertised SRv6 SID as + a 128-bit value. + +7. 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. + +7.1. SRv6 Endpoint Behavior TLV + + Each SRv6 SID instantiated on an SRv6-capable node has specific + instructions (called "behavior") bound to it. [RFC8986] 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 + (Section 7.2 of [RFC9352]) or the OSPFv3 SRv6 End SID sub-TLV + (Section 8 of [RFC9513]) 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: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: SRv6 Endpoint Behavior TLV + + 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 (Section 10.2 of [RFC8986]). + + 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. + +7.2. SRv6 BGP PeerNode SID TLV + + The BGP PeerNode and PeerSet SIDs for SR-MPLS are specified in + [RFC9086]. Similar Peer Node and Peer Set functionality can be + realized with SRv6 using SIDs with END.X behavior. Refer to + Appendix A 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: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: SRv6 BGP PeerNode SID TLV Format + + where: + + Type: 1251 + + Length: 12 + + Flags: 1 octet of flags with the following definitions: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |B|S|P| | + +-+-+-+-+-+-+-+-+ + + Figure 9: SRv6 BGP EPE SID Flags Format + + 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 (Section 4.1). + + 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: 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. + +8. 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 [RFC8986]. 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 + (Section 9 of [RFC9352]) or the OSPFv3 SRv6 SID Structure sub-TLV + (Section 10 of [RFC9513]) 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: + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: SRv6 SID Structure TLV + + 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. + +9. 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. + +9.1. BGP-LS NLRI Types + + IANA has assigned the following code points in the "BGP-LS NLRI + Types" registry: + + +======+===============+===========+ + | Type | NLRI Type | Reference | + +======+===============+===========+ + | 6 | SRv6 SID NLRI | RFC 9514 | + +------+---------------+-----------+ + + Table 1: Addition to BGP-LS NLRI + Types Registry + +9.2. BGP-LS NLRI and Attribute TLVs + + IANA has assigned the following TLV code points in the "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 | + +----------------+---------------------------+-----------+ + + Table 2: Additions to BGP-LS NLRI and Attribute TLVs + Registry + +9.3. 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 [RFC8126]. + + The initial contents of the registry are as follows: + + +=====+==========================+===========+ + | 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 | | + +-----+--------------------------+-----------+ + + Table 3: New SRv6 BGP EPE SID Flags Registry + +10. Manageability Considerations + + This section is structured as recommended in [RFC5706]. + + The new protocol extensions introduced in this document augment the + existing IGP topology information that is distributed via [RFC7752]. + Procedures and protocol extensions defined in this document do not + affect the BGP protocol operations and management other than as + discussed in Section 6 (Manageability Considerations) of [RFC7752]. + Specifically, the malformed attribute tests for syntactic checks in + Section 6.2.2 (Fault Management) of [RFC7752] 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 [RFC9086] 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 [RFC7752]. The manageability aspects of the underlying + SRv6 features are covered by [SRV6-YANG]. + +11. Security Considerations + + The new protocol extensions introduced in this document augment the + existing IGP topology information that is distributed via [RFC7752]. + 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 [RFC7752]. Section 8 + (Security Considerations) of [RFC7752] 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 + [RFC7752]. + + The extensions introduced in this document are used to propagate IGP- + defined information [RFC9352] [RFC9513]. 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 [RFC9352] and [RFC9513]). + + The security considerations related to BGP EPE functionality are + discussed in [RFC9086] 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 [RFC8402], 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. + +12. References + +12.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + <https://www.rfc-editor.org/info/rfc7752>. + + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + <https://www.rfc-editor.org/info/rfc8126>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, + July 2018, <https://www.rfc-editor.org/info/rfc8402>. + + [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., + and N. Triantafillis, "Signaling Maximum SID Depth (MSD) + Using the Border Gateway Protocol - Link State", RFC 8814, + DOI 10.17487/RFC8814, August 2020, + <https://www.rfc-editor.org/info/rfc8814>. + + [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, + D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 + (SRv6) Network Programming", RFC 8986, + DOI 10.17487/RFC8986, February 2021, + <https://www.rfc-editor.org/info/rfc8986>. + + [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, + H., and M. Chen, "Border Gateway Protocol - Link State + (BGP-LS) Extensions for Segment Routing", RFC 9085, + DOI 10.17487/RFC9085, August 2021, + <https://www.rfc-editor.org/info/rfc9085>. + + [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., + Ray, S., and J. Dong, "Border Gateway Protocol - Link + State (BGP-LS) Extensions for Segment Routing BGP Egress + Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August + 2021, <https://www.rfc-editor.org/info/rfc9086>. + + [RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B., + and Z. Hu, "IS-IS Extensions to Support Segment Routing + over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352, + February 2023, <https://www.rfc-editor.org/info/rfc9352>. + + [RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak, + "OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)", + RFC 9513, DOI 10.17487/RFC9513, December 2023, + <https://www.rfc-editor.org/info/rfc9513>. + +12.2. Informative References + + [RFC5706] Harrington, D., "Guidelines for Considering Operations and + Management of New Protocols and Protocol Extensions", + RFC 5706, DOI 10.17487/RFC5706, November 2009, + <https://www.rfc-editor.org/info/rfc5706>. + + [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., + Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header + (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, + <https://www.rfc-editor.org/info/rfc8754>. + + [SRV6-YANG] + Raza, S., Agarwal, S., Liu, X., Hu, Z., Hussain, I., Shah, + H. C., Voyer, D., Matsushima, S., Horiba, K., + Rajamanickam, J., and A. Abdelsalam, "YANG Data Model for + SRv6 Base and Static", Work in Progress, Internet-Draft, + draft-ietf-spring-srv6-yang-02, 23 September 2022, + <https://datatracker.ietf.org/doc/html/draft-ietf-spring- + srv6-yang-02>. + +Appendix A. 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 [RFC9086]. 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 Peter Psenak, Arun Babu, Pablo + Camarillo, Francois Clad, Peng Shaofu, Cheng Li, Dhruv Dhody, Tom + Petch, and Dan Romascanu for their review of this document and their + comments. The authors would also like to thank Susan Hares for her + shepherd review and Adrian Farrel for his detailed Routing Area + Directorate review. + +Contributors + + James Uttaro + AT&T + United States of America + Email: ju1738@att.com + + + Hani Elmalky + Ericsson + United States of America + Email: hani.elmalky@gmail.com + + + Arjun Sreekantiah + Individual + United States of America + Email: arjunhrs@gmail.com + + + Les Ginsberg + Cisco Systems + United States of America + Email: ginsberg@cisco.com + + + Shunwan Zhuang + Huawei + China + Email: zhuangshunwan@huawei.com + + +Authors' Addresses + + Gaurav Dawra + LinkedIn + United States of America + Email: gdawra.ietf@gmail.com + + + Clarence Filsfils + Cisco Systems + Belgium + Email: cfilsfil@cisco.com + + + Ketan Talaulikar (editor) + Cisco Systems + India + Email: ketant.ietf@gmail.com + + + Mach(Guoyi) Chen + Huawei + China + Email: mach.chen@huawei.com + + + Daniel Bernier + Bell Canada + Canada + Email: daniel.bernier@bell.ca + + + Bruno Decraene + Orange + France + Email: bruno.decraene@orange.com |