RFC 9514

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing over IPv6 (SRv6)

📅 published December 2023, from ietf
  • Stream: Internet Engineering Task Force (IETF) 💖
  • Request for Comments: 9514 ✨
  • Category: Standards Track 👑
  • ISSN: 2070-1721
  • Date: December 2023 🌸
  • Authors: G. Dawra (LinkedIn), C. Filsfils, K. Talaulikar, Ed. (Cisco Systems), M. Chen (Huawei), D. Bernier (Bell Canada), and B. Decraene (Orange) 🫶
  • Obsoletes / Updates: the title block doesn't list anything here, so there's nothing it obsoletes or updates 🦋

Abstract

okay bestie, so Segment Routing over IPv6 (SRv6) lets you describe end-to-end paths through all kinds of topologies by writing them as sequences of sub-paths called "segments" 🧚. These segments get advertised by protocols like BGP, IS-IS, and OSPFv3 💅.

This document extends BGP - Link State (BGP-LS) so it can advertise SRv6 segments, their behaviors, and other attributes over BGP ✨. The BGP-LS address-family solution for SRv6 here is basically the same vibe as BGP-LS for SR on the MPLS data plane, which is defined in RFC 9085 🦋.

Status of This Memo

This is an Internet Standards Track document 👑.

It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🫶. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 💖. If you want more on Internet Standards, check Section 2 of RFC 7841 🌈.

For the current status, any errata, and how to send feedback on this document, go to https://www.rfc-editor.org/info/rfc9514 🔥.

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) as they're in effect on the date of publication 💅. Please read these carefully, because they spell out your rights and restrictions for 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 they come 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 is Segment Routing running on the IPv6 data plane [RFC8402] 🌈. An SRv6 segment is usually called by its SRv6 Segment Identifier (SID) 💖.

The network programming paradigm [RFC8986] is the core of SRv6 🧚. It explains how different behaviors get bound to SIDs, and how a network program can be written as a combination of SIDs 👑.

An SRv6-capable node keeps track of all the SRv6 segments that are explicitly instantiated locally 🫶.

The IS-IS and OSPFv3 link-state routing protocols were extended to advertise some of these SRv6 SIDs and SRv6-related info [RFC9352] [RFC9513] 💅. Other SRv6 SIDs might be instantiated on a node through other mechanisms, for topological or service functions 🦋.

Advertising SR-related info 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) 🌸. Following the same idea, putting SRv6-related info into BGP-LS lets consumer applications that need topological visibility also receive the SRv6 SIDs from nodes across an IGP domain, or even across Autonomous Systems (ASes) when needed 🎀. That means applications can use SRv6 capabilities for network programming 🔥.

The identifying key of each link-state object (a node, link, or prefix) is encoded in the Network Layer Reachability Information (NLRI), and the properties of that object are encoded in the BGP-LS Attribute [RFC7752] 💜.

This document describes the BGP-LS extensions that advertise the SRv6 SIDs and other SRv6 info from all the SRv6-capable nodes in the IGP domain when they're sourced from link-state routing protocols, and directly from individual SRv6-capable nodes (for example, 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, plus how their attributes get advertised over BGP 💖.

When a BGP-LS router advertises topology info that comes from the underlying link-state routing protocol, it works out the matching SRv6 info from the SRv6 extensions for IS-IS [RFC9352] or OSPFv3 [RFC9513], whichever applies 💅. In practice this derivation is a simple copy of the relevant fields from the IS-IS or OSPFv3 TLV/sub-TLV into the fields of the matching BGP-LS TLV/sub-TLV 🫶. When a BGP-LS router advertises topology info from the BGP routing protocol (for example, for EPE), or advertises SRv6 SIDs tied to a node using Direct as the Protocol-ID, it derives the SRv6 info from the local node 🧚. That info is only advertised on behalf of the local router, which is different from advertising info from all nodes of an IGP domain when it's sourced from a link-state routing protocol 🌸.

The SRv6 info for a node gets advertised via the BGP-LS Node NLRI, using BGP-LS Attribute TLVs, like so:

  • The SRv6 capabilities of the node go out 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 info for a link gets advertised via the BGP-LS Link NLRI, using BGP-LS Attribute TLVs, like this:

  • 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 info for a prefix gets advertised via the BGP-LS Prefix NLRI, using 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 tied to the node are advertised using the BGP-LS SRv6 SID NLRI introduced in this document (Section 6) 🌸. This lets the BGP-LS encoding scale to a potentially large set of SRv6 SIDs instantiated on a node, at the granularity of individual SIDs, without messing with the size and scalability of the BGP-LS updates 🧚. If the SRv6 SIDs had been advertised inside the BGP-LS Link Attribute tied to the existing Node NLRI, the BGP-LS update would've grown pretty huge as the number of SRv6 SIDs on the node went up. It would also need a big update message for any change, even a change to just one SRv6 SID 🙈. The 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) ✨.

The later sections of this document specify the encoding and usage of these extensions 💖. All the TLVs introduced here follow the formats and common field definitions given 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 they're 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 it indicates the SRv6 support of 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 defined right now 🌸. Also, the SRv6 Capabilities TLV defined below is not extensible 💜. So it's 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: a 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]), depending on whether it's IS-IS or OSPFv3 💅.
  • Reserved: a 2-octet field that MUST be set to 0 when originated and ignored on receipt 🌸.

Part 1 of 5 done, bestie! 💖 Keep your eyes peeled for part 2 🦋

3.2. SRv6 Node MSD Types 🎀

okay so the Node MSD TLV [RFC8814] in the BGP-LS Attribute of the Node NLRI is ALSO used to advertise the limits and the Segment Routing Header (SRH) [RFC8754] operations that an SRv6-capable node supports 🦋 the SRv6 MSD types from Section 4 of [RFC9352] get reused here too, because these code points are shared between IS-IS, OSPF, and BGP-LS. the description and semantics of these new MSD types for BGP-LS are identical to the ones in [RFC9352], so no new rules, just the same vibes 💅

each MSD type gets encoded in the BGP-LS Node MSD TLV as a one-octet type, then a one-octet value. that value is derived from the IS-IS or OSPFv3 Node MSD advertisements from [RFC8814]. it's giving consistency 🫶

SRv6 attributes and SIDs tied to a link or adjacency get advertised using the BGP-LS Attribute TLVs defined in this section, and they're associated with the BGP-LS Link NLRI. the link era is here 🔥

4.1. SRv6 End.X SID TLV 💜

the SRv6 End.X SID TLV advertises the SRv6 SIDs linked to an IGP Adjacency SID behavior. this covers a point-to-point or point-to-multipoint link or adjacency on a node running IS-IS or OSPFv3. the info is derived from the IS-IS SRv6 End.X SID sub-TLV (Section 8.1 of [RFC9352]), or from the OSPFv3 SRv6 End.X SID sub-TLV (Section 9.1 of [RFC9513]) depending on which protocol we're talking about. bonus: this TLV can also carry the SRv6 SID for the underlying Layer 2 member links of a Layer 3 bundle interface, as a sub-TLV of the L2 Bundle Member Attribute TLV [RFC9085] 🌸

BGP-LS also uses this TLV to advertise the BGP EPE Peer Adjacency SID for SRv6, following the same approach as SR-MPLS in [RFC9086]. the SRv6 SID for the BGP Peer Adjacency uses End.X behaviors (that's End.X, End.X with PSP, End.X with USP, and End.X with PSP & USP) from [RFC8986]. it points at a specific Layer 3 link to a specific BGP session peer (neighbor) 🧚

you can include more than one instance of this TLV in the BGP-LS Attribute, one for each SRv6 End.X SID 🍓

the TLV looks like this:

 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

here's what each bit means 👑

  • Type: 1106
  • Length: variable
  • Endpoint Behavior: a 2-octet field. it holds the Endpoint behavior code point for this SRv6 SID, as defined in Section 10.2 of [RFC8986] ✨
  • Flags: 1 octet of flags. they're 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]), depending on whether it's IS-IS or OSPFv3. for the BGP EPE Peer Adjacency SID, the flags are as defined in Section 7.2 💖
  • Algorithm: a 1-octet field. the algorithm associated with the SID 🦋
  • Weight: a 1-octet field. it's the weight of the SID for load balancing. the use of the weight is defined in [RFC8402] ⭐
  • Reserved: a 1-octet field that MUST be set to 0 when originated and ignored on receipt. don't touch it, bestie 🙈
  • SID: a 16-octet field. it encodes the advertised SRv6 SID as a 128-bit value 🌈
  • Sub-TLVs: these give extra attributes for the specific SRv6 SID. this document defines one of them in Section 8 🍓

4.2. SRv6 LAN End.X SID TLV 🌸

on a LAN interface, an IGP node normally only announces its adjacency to the IS-IS pseudonode (or the equivalent OSPF DR). the info here is derived from the IS-IS SRv6 LAN End.X SID sub-TLV (Section 8.2 of [RFC9352]), or from the OSPFv3 SRv6 LAN End.X SID sub-TLV (Section 9.2 of [RFC9513]), depending on the protocol. the SRv6 LAN End.X SID TLV lets a node announce the SRv6 SID for its adjacencies to all the other (i.e., non-DIS or non-DR) nodes on the LAN in one single BGP-LS Link NLRI instance 🧚 without it, you'd need a separate BGP-LS Link NLRI for every neighbor just to advertise the SRv6 End.X SID TLVs for those non-DIS/non-DR neighbors. so much extra work, no thank you 😭

the SRv6 SIDs for these IGP adjacencies, using End.X behaviors (End.X, End.X with PSP, End.X with USP, and End.X with PSP & USP) from [RFC8986], get advertised with the SRv6 LAN End.X SID TLV ✨

you can include more than one instance of this TLV in the BGP-LS Attribute, one for each SRv6 LAN End.X SID 💅

the BGP-LS IS-IS SRv6 LAN End.X SID and BGP-LS OSPFv3 SRv6 LAN End.X SID TLVs both look like this:

 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

the breakdown 🫶

  • Type: 1107 for IS-IS and 1108 for OSPFv3
  • Length: variable
  • Endpoint Behavior: a 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. they're 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]), depending on whether it's IS-IS or OSPFv3 ✨
  • Algorithm: a 1-octet field. the algorithm associated with the SID 💜
  • Weight: a 1-octet field. it's the weight of the SID for load balancing 🍓
  • Reserved: a 1-octet field that MUST be set to 0 when originated and ignored on receipt. same rule as before, no exceptions 💀
  • 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: a 16-octet field. it encodes the advertised SRv6 SID as a 128-bit value 🌈
  • Sub-TLVs: these give extra attributes for the specific SRv6 SID. this document defines one of them in Section 8 👑

the Link MSD TLV [RFC8814] in the BGP-LS Attribute of the Link NLRI is ALSO used to advertise the limits and the SRH operations that the SRv6-capable node supports on that specific link. the SRv6 MSD types from Section 4 of [RFC9352] get used with the BGP-LS Link MSD TLV too, since these code points are shared between IS-IS, OSPF, and BGP-LS. the description and semantics of these new MSD types for BGP-LS are identical to what's specified in [RFC9352] 💖

each MSD type gets encoded in the BGP-LS Link MSD TLV as a one-octet type followed by a one-octet value, derived from the IS-IS or OSPFv3 Link MSD advertisements specified in [RFC8814] ✨

5. SRv6 Prefix Attributes 🌈

SRv6 attributes with an IPv6 prefix get advertised using the BGP-LS Attribute TLVs defined in this section, and they're associated with the BGP-LS Prefix NLRI. next up, the prefix era 🧚

5.1. SRv6 Locator TLV 🎀

okay so, per [RFC8986], an SRv6 SID is built from three parts: a locator, a function, and an argument 💖

every node gets provisioned with one or more locators that it supports 🦋 locators are covering prefixes for the whole pile of SIDs living on that node. each locator gets advertised as a BGP-LS Prefix NLRI object, and the SRv6 Locator TLV rides along inside its BGP-LS Attribute ✨

the info in this TLV is copied over from the IS-IS SRv6 Locator TLV (Section 7.1 of [RFC9352]) or the OSPFv3 SRv6 Locator TLV (Section 7.1 of [RFC9513]), depending on which protocol you're running 🌈

the IPv6 Prefix that matches the locator can also show up as plain prefix reachability from the underlying routing protocol 💅 when that happens, the Prefix NLRI gets paired with the Prefix Metric TLV [RFC7752], which carries the routing metric for that prefix. a Prefix NLRI that came with an SRv6 Locator TLV only counts as a normal routing prefix (so, prefix reachability) when there's also an IGP Metric TLV (TLV 1095) attached to it. if there isn't one, it's just an SRv6 Locator advertisement and that's it 🙈

here's the 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) . . .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     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]), depending on whether it's IS-IS or OSPFv3 💖
  • Algorithm: 1-octet field. The 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 metric value 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]), again depending on the protocol 🌸
  • Sub-TLVs: used to advertise sub-TLVs that give extra attributes for the SRv6 Locator. Right now, none are defined 🧚

6. SRv6 SID NLRI ✨

okay this part is so cute 🥹 the Link-State NLRI defined in [RFC7752] gets extended to carry SRv6 SID info 💅

this document defines a brand new Link-State NLRI type for SRv6 SID information: SRv6 SID NLRI (type 6) 🦋

the SRv6 SIDs tied to a node get 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: a set of Node Descriptor TLVs for the local node. These are defined in [RFC7752] for IGPs, for the Direct Protocol-ID, and for the Static configuration Protocol-ID, or they're defined in [RFC9086] for BGP 💅
  • SRv6 SID Descriptors: a 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 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's tied to the node and advertised with the SRv6 SID NLRI gets encoded using the SRv6 SID Information TLV 💖

when the SRv6 SIDs come from the IGPs, the SID info 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]), depending on whether it's IS-IS or OSPFv3 ✨

the TLV also carries the SRv6 SIDs that match the BGP PeerNode and PeerSet SIDs [RFC8402], but only 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 that get 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 get bound to a SID, and it also defines the initial set of well-known behaviors ✨

the SRv6 Endpoint Behavior TLV is a mandatory TLV. It MUST be included in the BGP-LS Attribute associated with the BGP-LS SRv6 SID NLRI 🔥

when the SRv6 SIDs come 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]), depending on the protocol 🦋

when the SRv6 SIDs correspond to the BGP EPE functionality, the Endpoint behavior corresponds to End.X and similar behaviors. When the SRv6 SIDs 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 the SID was allocated from 💖

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 Format

where:

  • Type: 1250
  • Length: 4
  • Endpoint Behavior: 2-octet field. The Endpoint behavior code point for this SRv6 SID. Values come 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 that correspond to IGPs. No flags are currently defined for SRv6 SIDs that correspond to BGP EPE, or for advertising an 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 💖

okay so 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 ✨ Check out Appendix A for some differences between how these SIDs get signaled in SR-MPLS and SRv6 💅 The SRv6 BGP PeerNode SID TLV is a mandatory TLV for the BGP-LS Attribute of an SRv6 SID NLRI advertised by BGP for the EPE functionality. Bestie, 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's an optional TLV for the BGP-LS Attribute of an SRv6 SID NLRI, and it also shows up 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 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. Bestie, that's a hard rule, so keep those lengths in check 😭

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 🔒

okay bestie, this part is serious, but security is still giving main character energy 💅 The new protocol extensions in this document add to the IGP topology info that already gets shared via [RFC7752]. Advertising the SRv6 link-state info defined here carries a similar risk to the link-state info that already exists, as described in [RFC7752]. Section 8 (Security Considerations) of [RFC7752] also applies to these extensions. On their own, the procedures and new TLVs in this document don't change the BGP-LS security model covered in [RFC7752] 🛡️

The extensions in this document are used to spread IGP-defined info [RFC9352] [RFC9513]. They carry SRv6 info tied to the IGP node, link, and prefix. The IGP instances that originate these TLVs are assumed to support all the required security and authentication mechanisms (as described in [RFC9352] and [RFC9513]) 🔐

The security stuff for BGP EPE is covered in [RFC9086] for SR-MPLS, and it applies to this document for SRv6 too ✨

BGP-LS SRv6 extensions make traffic-engineering use cases possible inside the SR domain. SR works inside a trusted domain [RFC8402], and that security reasoning also covers BGP-LS sessions that carry SR info. The SR traffic-engineering policies that use SIDs advertised over BGP-LS are expected to stay entirely inside this trusted SR domain (for example, between several AS or IGP domains within one provider network). So you need to take real care to make sure the link-state info (including SRv6 info) advertised over BGP-LS sessions only reaches consumers inside this trusted SR domain 🚧 BGP peering sessions for address families other than Link State may be set up with routers outside the SR domain. Isolating BGP-LS peering sessions is RECOMMENDED so that BGP-LS topology info (including the newly added SR info) doesn't get advertised to any external BGP peering session outside the SR domain 🙅‍♀️🌈

12. References 📚

12.1. Normative References

12.2. Informative References

Appendix A. Differences with BGP-EPE for SR-MPLS 🦋

okay so this appendix is the compare-and-contrast moment 👀 The SRv6 SID signaling for BGP-EPE functionality defined in this document is different from the SR-MPLS BGP-EPE SID signaling in [RFC9086]. This section gives a high-level overview of those differences 💕

The BGP Peer Adjacency SID is advertised the exact same way in SR-MPLS and SRv6. It's an attribute of the Link NLRI, which identifies a specific Layer 3 interface on the BGP Speaker. The difference is in how the BGP PeerNode and PeerSet SIDs are advertised 🫶

For SR-MPLS, an extra Link NLRI has to be advertised for each BGP peering session on the node. This isn't the same Link NLRI tied to the actual Layer 3 interface, even when the peering is set up using the interface IP addresses. These BGP-LS Link NLRIs aren't really links in the normal link-state routing data model. They identify BGP peering sessions instead. The BGP PeerNode and/or PeerSet SIDs for that peering session are advertised as attributes of this peering Link NLRI. For SRv6, each BGP PeerNode or PeerSet SID is treated as belonging to the BGP Speaker Node and is advertised using the BGP-LS SRv6 SID NLRI, while the peering session info is advertised as attributes attached to it 🌸

For SR-MPLS, the BGP PeerSet SID is advertised by including that SID as an attribute in every Link NLRI for the peering sessions that are part of the "set". For SRv6, the BGP PeerSet SID is advertised using one single SRv6 SID NLRI, and all the peers in that "set" are indicated as attributes of that NLRI 💅

Acknowledgements 🫶

Huge thank-yous to Peter Psenak, Arun Babu, Pablo Camarillo, Francois Clad, Peng Shaofu, Cheng Li, Dhruv Dhody, Tom Petch, and Dan Romascanu for reviewing this document and sharing their comments 💖 The authors also want 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
📦 where this page comes from