RFC 9831

Segment Type Extensions for BGP Segment Routing (SR) Policy

📅 published September 2025, from ietf

🎀 RFC 9831: Segment Type Extensions for BGP Segment Routing (SR) Policy 🦋

Okay bestie, this RFC is giving experimental vibes ✨. It's not a Standards Track doc, it's basically a "try it, poke at it, tell us what breaks" kinda thing 🧪💅. It was written by K. Talaulikar (Ed.), C. Filsfils (Cisco Systems), S. Previdi (Huawei Technologies), P. Mattes (Microsoft), and D. Jain (Google). The date is September 2025, the category is Experimental, and the ISSN is 2070-1721. It doesn't obsolete anything and it doesn't update anything either, so it's a fresh little baby RFC 🍓. It's the sequel to RFC 9830, which introduced the BGP SR Policy SAFI, so this one is basically the "okay now let's add the rest of the segment types" episode 📺✨.

Abstract ✨

So the TL;DR is: this doc specifies how to signal extra Segment Routing Segment Types for SR Policies in BGP, using the SR Policy Subsequent Address Family Identifier (SAFI) 💖.

Status of This Memo 📜

Lowkey the most important vibe check here: this is not an Internet Standards Track spec. It's published for examination, experimental implementation, and evaluation 🧪. It IS a product of the IETF and it did get consensus and public review and IESG approval 🫶. But not every IESG-approved doc is a candidate for an Internet Standard, so don't go treating this like gospel yet 🙈. For the deets on that, check Section 2 of RFC 7841. Also, errata and feedback info live at https://www.rfc-editor.org/info/rfc9831 🔗.

Copyright (c) 2025 IETF Trust and the document authors, all rights reserved 🌈. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions (https://trustee.ietf.org/license-info) as of the publication date, so read those if you care about your rights and restrictions 📚. Also, any Code Components you pull out of this doc need Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty under that license 🔥.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
2.  Segment Type Sub-TLVs
  2.1.  Segment Type C
  2.2.  Segment Type D
  2.3.  Segment Type E
  2.4.  Segment Type F
  2.5.  Segment Type G
  2.6.  Segment Type H
  2.7.  Segment Type I
  2.8.  Segment Type J
  2.9.  Segment Type K
  2.10. SR Policy Segment Flags
3.  IANA Considerations
  3.1.  SR Policy Segment List Sub-TLVs
  3.2.  SR Policy Segment Flags
4.  Security Considerations
5.  Manageability Considerations
6.  Normative References
Acknowledgments
Authors' Addresses

1. Introduction 🌸

Okay so the BGP SR Policy SAFI got introduced by [RFC9830] for advertising SR Policies [RFC8402] 💅. And [RFC9830] brought in the basic Segment Types A and B, which come from the SR Policy Architecture [RFC9256] 🧚.

This doc is where we add the rest of the Segment Types from [RFC9256], and it covers both SR-MPLS (see [RFC8660]) and Segment Routing over IPv6 (SRv6) (see [RFC8754] and [RFC8986]) 🦋✨. Bestie, the good news is that none of this changes how SR Policy operations or fault management work, as specified in [RFC9830] 🫶.

1.1. Requirements Language 📖

Here's the key word situation 🔑: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in ALL CAPS like that 💖. Any other casing is just regular English, no cap 🙈.

2. Segment Type Sub-TLVs 🎀

So the Segment List sub-TLV [RFC9830] encodes one explicit path to the endpoint, as described in Section 5.1 of [RFC9256] 🛤️. The elements of that path (aka the segments) live inside it 🧩.

A Segment sub-TLV is one single segment in a segment list, aka one element of that explicit path 💅.

Section 4 of [RFC9256] defines a bunch of Segment Types for SR-MPLS and SRv6. Here's the reminder list, bestie 📝:

Type A:   SR-MPLS Label

Type B:   SRv6 SID

Type C:   IPv4 Prefix with optional SR Algorithm

Type D:   IPv6 Global Prefix with optional SR Algorithm for SR-MPLS

Type E:   IPv4 Prefix with Local Interface ID

Type F:   IPv4 Addresses for link endpoints as Local, Remote pair

Type G:   IPv6 Prefix and Interface ID for link endpoints as Local,
          Remote pair for SR-MPLS

Type H:   IPv6 Addresses for link endpoints as Local, Remote pair for
          SR-MPLS

Type I:   IPv6 Global Prefix with optional SR Algorithm for SRv6

Type J:   IPv6 Prefix and Interface ID for link endpoints as Local,
          Remote pair for SRv6

Type K:   IPv6 Addresses for link endpoints as Local, Remote pair for
          SRv6

So [RFC9830] already handles Types A and B 🫶. The subsections below are where we spell out the sub-TLVs for every other type on that list 🌈.

Quick heads up: per Sections 2.4.4 and 2.4.4.2 of [RFC9830], validating an explicit path encoded by the Segment List sub-TLV is beyond the scope of BGP. That job belongs to the Segment Routing Policy Module (SRPM), as described in Section 5 of [RFC9830] 🧠. And as Section 5.1 of [RFC9256] says, mixing SR-MPLS and SRv6 segments in one segment-list makes it invalid 🚫💀.

2.1. Segment Type C 🌷

The Type C Segment sub-TLV encodes an IPv4 node address, an SR Algorithm, and an optional SR-MPLS Segment Identifier (SID) 🧚. Here's the layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |     Flags     |  SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Type C Segment Sub-TLV

Here's the breakdown, bestie 💅:

  • Type: 3
  • Length: the length of the value field in octets (so NOT counting Type and Length). It MUST be 10 when the SR-MPLS SID is present, and otherwise it MUST be 6 📏.
  • Flags: 1 octet of flags, defined in Section 2.10 🚩.
  • SR Algorithm: 1 octet naming the SR Algorithm from Section 3.1.1 of [RFC8402], but only when the A-Flag (from Section 2.10) is set. The SRPM [RFC9830] uses the SR Algorithm as described in Section 4 of [RFC9256] 🧮. When the A-Flag is not set, this field MUST be set to zero on transmission and MUST be ignored on receipt 🙈.
  • IPv4 Node Address: a 4-octet IPv4 address for a node 🌐.
  • SR-MPLS SID: optional. A 4-octet field holding a label, Traffic Class (TC), bottom-of-stack (S), and TTL, as defined for Segment Type A [RFC9830] 🏷️.

2.2. Segment Type D 🌈

The Type D Segment sub-TLV encodes an IPv6 node address, an SR Algorithm, and an optional SR-MPLS SID 🦋. Here's the layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |     Flags     |  SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Node Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Type D Segment Sub-TLV

Breakdown time 💖:

  • Type: 4
  • Length: the value field length in octets (not counting Type and Length). It MUST be 22 when the SR-MPLS SID is present, and otherwise it MUST be 18 📏.
  • Flags: 1 octet of flags, defined in Section 2.10 🚩.
  • SR Algorithm: 1 octet naming the SR Algorithm from Section 3.1.1 of [RFC8402], but only when the A-Flag (from Section 2.10) is set. The SRPM [RFC9830] uses it as described in Section 4 of [RFC9256] 🧮. When the A-Flag is not set, this field MUST be set to zero on transmission and MUST be ignored on receipt 🙈.
  • IPv6 Node Address: a 16-octet IPv6 address for a node 🌍.
  • SR-MPLS SID: optional. A 4-octet field holding a label, TC, S, and TTL, as defined for Segment Type A [RFC9830] 🏷️.

2.3. Segment Type E 💜

The Type E Segment sub-TLV encodes an IPv4 node address, a local interface Identifier (Local Interface ID), and an optional SR-MPLS SID 🧚‍♀️. Here's the layout:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |     Flags     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Interface ID (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 IPv4 Node Address (4 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                SR-MPLS SID (optional, 4 octets)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Type E Segment Sub-TLV

Here's the Type E breakdown 🎀:

  • Type: 5
  • Length: the value field length in octets (not counting Type and Length). It MUST be 14 when the SR-MPLS SID is present, and otherwise it MUST be 10 📏.
  • Flags: 1 octet of flags, defined in Section 2.10 🚩.
  • RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt 🙈.
  • Local Interface ID: 4 octets carrying the interface index of the local interface (refer to TLV 258 of [RFC9552]) 🔌.
  • IPv4 Node Address: a 4-octet IPv4 address for a node 🌐.
  • SR-MPLS SID: optional. A 4-octet field holding a label, TC, S, and TTL, as defined for Segment Type A [RFC9830] 🏷️.

To be continued in Part 2 bestie! Stay tuned 🫶💖✨

2.4. Segment Type F

okay so Type F is the one that's all about an adjacency 💖 it carries a local address, a remote address, and an optional SR-MPLS SID. here's how it's laid out 🎀

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Local IPv4 Address (4 octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Remote IPv4 Address  (4 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 4: Type F Segment Sub-TLV

Where:

  • Type: 6
  • Length: the length of the value field (so NOT counting Type and Length) in octets. It MUST be 14 when the SR-MPLS SID is present; else, it MUST be 10. 🙈
  • Flags: 1 octet of flags, as defined in Section 2.10. 🦋
  • RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt. 💅
  • Local IPv4 Address: a 4-octet IPv4 address for the local link address of the node. ✨
  • Remote IPv4 Address: a 4-octet IPv4 address for the link address of the neighbor node. 🌸
  • SR-MPLS SID: optional. A 4-octet field holding a label, TC, S, and TTL, as defined for Segment Type A [RFC9830]. 🧚

2.5. Segment Type G

okay Type G is the IPv6 link-local version 🌈 so it encodes an IPv6 link-local adjacency: a local node address, a local interface ID, a remote node address, a remote interface ID, and an optional SR-MPLS SID. the layout is below 👑

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Local Interface ID (4 octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                IPv6 Local Node Address (16 octets)          //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Remote Interface ID (4 octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                IPv6 Remote Node Address (16 octets)         //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 5: Type G Segment Sub-TLV

Where:

  • Type: 7
  • Length: the length of the value field (not counting Type and Length) in octets. It MUST be 46 when the SR-MPLS SID is present; else, it MUST be 42. 💀
  • Flags: 1 octet of flags, as defined in Section 2.10. 🫶
  • RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt. 💜
  • Local Interface ID: 4 octets of interface index for the local interface (see TLV 258 of [RFC9552]). 🦋
  • IPv6 Local Node Address: a 16-octet IPv6 address for the node. ✨
  • Remote Interface ID: 4 octets of interface index for the remote interface (see TLV 258 of [RFC9552]). The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link. 🌷
  • IPv6 Remote Node Address: a 16-octet IPv6 address. The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link. 🍓
  • SR-MPLS SID: optional. A 4-octet field holding a label, TC, S, and TTL, as defined for Segment Type A [RFC9830]. 🧚

2.6. Segment Type H

Type H is basically Type F but make it IPv6 💅 it encodes an adjacency local address, an adjacency remote address, and an optional SR-MPLS SID. here's the picture 🌸

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Length      |     Flags     |   RESERVED    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //               Local IPv6 Address (16 octets)                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //               Remote IPv6 Address  (16 octets)              //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                SR-MPLS SID (optional, 4 octets)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: Type H Segment Sub-TLV

Where:

  • Type: 8
  • Length: the length of the value field (not counting Type and Length) in octets. It MUST be 38 when the SR-MPLS SID is present; else, it MUST be 34. 🙈
  • Flags: 1 octet of flags, as defined in Section 2.10. 🦋
  • RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt. 💅
  • Local IPv6 Address: a 16-octet IPv6 address for the local link address of the node. ✨
  • Remote IPv6 Address: a 16-octet IPv6 address for the link address of the neighbor node. 🌸
  • SR-MPLS SID: optional. A 4-octet field holding a label, TC, S, and TTL, as defined for Segment Type A [RFC9830]. 🧚

2.7. Segment Type I

Type I is the SRv6 one 🦋 it encodes an IPv6 node address, an SR Algorithm, and an optional SRv6 SID. the format goes 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      |     Flags     | SR Algorithm  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                 IPv6 Node Address (16 octets)               //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    SRv6 SID (optional, 16 octets)           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //           SRv6 Endpoint Behavior and SID Structure          //
   //                    (optional, 8 octets)                     //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 7: Type I Segment Sub-TLV

Where:

  • Type: 14
  • Length: the length of the value field (not counting Type and Length) in octets. It MUST be one of the following:
    • 42 when both SRv6 SID and SRv6 Endpoint Behavior and SID Structure are present,
    • 34 when only SRv6 SID is present, or
    • 18 when the SRv6 SID is not present. 🌈
  • Flags: 1 octet of flags, as defined in Section 2.10. 👑
  • SR Algorithm: 1 octet specifying the SR Algorithm as described in Section 3.1.1 of [RFC8402] when the A-Flag, as defined in Section 2.10, is set. The SR Algorithm is used by the SRPM [RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag is not set, this field MUST be set to zero on transmission and MUST be ignored on receipt. 🫶
  • IPv6 Node Address: a 16-octet IPv6 address for the node. 🍓
  • SRv6 SID: optional. A 16-octet IPv6 address. The value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior or SID Structure without specifying the SID. 🧚
  • SRv6 Endpoint Behavior and SID Structure: optional, as defined in Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior or SID Structure MUST NOT be included when the SRv6 SID has not been included. 💀

TLV 10 defined for the advertisement of Segment Type I in the early draft versions of [RFC9830] has been deprecated to avoid backward-compatibility issues. 🙈

2.8. Segment Type J ✨

Okay bestie, the Type J Segment sub-TLV is giving IPv6 link-local adjacency realness 💅 It encodes a local node address, a local interface identifier (Local Interface ID), a remote IPv6 node address, a remote interface identifier (Remote Interface ID), and an optional SRv6 SID. Here's the layout 🦋

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length      |     Flags     | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Local Interface ID (4 octets)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Local Node Address (16 octets)          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Remote Interface ID (4 octets)                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                IPv6 Remote Node Address (16 octets)         //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SRv6 SID (optional, 16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Type J Segment Sub-TLV

Where:

Type: 15

Length: Tells you how long the value field is, in octets (so not counting the Type and Length fields) 🎀 The value MUST be one of the following:

  • 66 when both SRv6 SID and SRv6 Endpoint Behavior and SID Structure are present,
  • 58 when only SRv6 SID is present, or
  • 42 when the SRv6 SID is not present.

Flags: 1 octet of flags as defined in Section 2.10.

SR Algorithm: 1 octet specifying the SR Algorithm as described in Section 3.1.1 of [RFC8402] when the A-Flag as defined in Section 2.10 is set. The SR Algorithm is used by the SRPM [RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag is not set, this field MUST be set to zero on transmission and MUST be ignored on receipt.

Local Interface ID: 4 octets of interface index of local interface (refer to TLV 258 of [RFC9552]).

IPv6 Local Node Address: A 16-octet IPv6 address representing the node.

Remote Interface ID: 4 octets of interface index of remote interface (refer to TLV 258 of [RFC9552]). The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link.

IPv6 Remote Node Address: A 16-octet IPv6 address. The value MAY be set to zero when the local node address and interface identifiers are sufficient to describe the link.

SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior or SID Structure without specifying the SID.

SRv6 Endpoint Behavior and SID Structure: Optional, as defined in Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior and SID Structure MUST NOT be included when the SRv6 SID has not been included.

TLV 11 defined for the advertisement of Segment Type J in the early draft versions of [RFC9830] has been deprecated to avoid backward-compatibility issues. 🙈

2.9. Segment Type K 🌸

Next up is Type K, which encodes an adjacency local address, an adjacency remote address, and an optional SRv6 SID. Same energy as J, just a little simpler 💖 Here's the 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     | SR Algorithm  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Local IPv6 Address (16 octets)                //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//               Remote IPv6 Address  (16 octets)              //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                SRv6 SID (optional, 16 octets)               //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Type K Segment Sub-TLV

Where:

Type: 16

Length: Tells you how long the value field is, in octets (so not counting the Type and Length fields). The value MUST be one of the following:

  • 58 when both SRv6 SID and SRv6 Endpoint Behavior and SID Structure are present,
  • 50 when only SRv6 SID is present, or
  • 34 when the SRv6 SID is not present.

Flags: 1 octet of flags as defined in Section 2.10.

SR Algorithm: 1 octet specifying the SR Algorithm as described in Section 3.1.1 of [RFC8402] when the A-Flag as defined in Section 2.10 is set. The SR Algorithm is used by the SRPM [RFC9830] as described in Section 4 of [RFC9256]. When the A-Flag is not set, this field MUST be set to zero on transmission and MUST be ignored on receipt.

Local IPv6 Address: A 16-octet IPv6 address representing the local link address of the node.

Remote IPv6 Address: A 16-octet IPv6 address representing the link address of the neighbor node.

SRv6 SID: Optional. A 16-octet IPv6 address. The value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior or SID Structure without specifying the SID.

SRv6 Endpoint Behavior and SID Structure: Optional, as defined in Section 2.4.4.2.4 of [RFC9830]. The SRv6 Endpoint Behavior and SID Structure MUST NOT be included when the SRv6 SID has not been included.

TLV 12 defined for the advertisement of Segment Type K in the early draft versions of [RFC9830] has been deprecated to avoid backward-compatibility issues. 💅

2.10. SR Policy Segment Flags 🦋

The Segment Type sub-TLVs described above may contain the following SR Policy Segment Flags [RFC9830] in their Flags field (see also Section 3.2). This document introduces additional flags below:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A|S|B|       |
+-+-+-+-+-+-+-+-+

Figure 10: SR Policy Segment Flags

Where:

V-Flag: This is an existing flag as defined in [RFC9830].

A-Flag: When set, this flag indicates the presence of the SR Algorithm id in the SR Algorithm field applicable to various Segment Types. The SR Algorithm is used by the SRPM [RFC9830] as described in Section 4 of [RFC9256].

S-Flag: When set, this flag indicates the presence of the SR-MPLS or SRv6 SID depending on the segment type.

B-Flag: This is an existing flag as defined in [RFC9830].

The following applies to the Segment Flags:

  • The V-Flag applies to all Segment Types including those introduced by this document.
  • The A-Flag applies to Segment Types C, D, I, J, and K. The value of the A-Flag MUST be ignored for Segment Types A, B, E, F, G, and H.
  • The S-Flag applies to Segment Types C, D, E, F, G, H, I, J, and K. The value of the S-Flag MUST be ignored for Segment Types A and B.
  • The B-Flag applies to Segment Types B, I, J, and K. The value of the B-Flag MUST be ignored for Segment Types A, C, D, E, F, G, and H.

3. IANA Considerations 🎀

3.1. SR Policy Segment List Sub-TLVs 🌈

IANA has allocated the following code points from the "SR Policy Segment List Sub-TLVs" registry [RFC9830] under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.

              +=======+========================+===========+
              | Value | Description            | Reference |
              +=======+========================+===========+
              | 3     | Type C Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 4     | Type D Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 5     | Type E Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 6     | Type F Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 7     | Type G Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 8     | Type H Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 14    | Type I Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 15    | Type J Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+
              | 16    | Type K Segment sub-TLV | RFC 9831  |
              +-------+------------------------+-----------+

               Table 1: SR Policy Segment List Code Points

3.2. SR Policy Segment Flags 🍓

IANA has allocated code points from the "SR Policy Segment Flags" registry [RFC9830] under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.

             +=====+=============================+===========+
             | Bit | Description                 | Reference |
             +=====+=============================+===========+
             | 1   | SR Algorithm Flag (A-Flag)  | RFC 9831  |
             +-----+-----------------------------+-----------+
             | 2   | SID Specified Flag (S-Flag) | RFC 9831  |
             +-----+-----------------------------+-----------+

                      Table 2: SR Policy Segment Flags

4. Security Considerations 🔥

The security considerations in [RFC9830] apply to the Segment Types defined in this document. No additional security considerations are introduced.

5. Manageability Considerations ⭐

The operations and manageability considerations in [RFC9830] apply to the Segment Types defined in this document. No additional operations and manageability considerations are introduced.

6. Normative References 📚

Okay bestie, these are the must-read docs 🤓 Every one of these is a reference the spec leans on, so I've kept all the details exactly as they are.

Acknowledgments 🫶

The authors would like to Dan Romascanu, Stig Venaas, and Russ Housley for their comments and review. 💖 The authors would also like to thank Susan Hares for her detailed shepherd review, which helped make the document better. 🥹✨

Authors' Addresses 🌈

Ketan Talaulikar (editor) 💅 Cisco Systems India Email: ketant.ietf@gmail.com

Clarence Filsfils 💅 Cisco Systems Brussels Belgium Email: cfilsfil@cisco.com

Stefano Previdi 💅 Huawei Technologies Italy Email: stefano@previdi.net

Paul Mattes 💅 Microsoft One Microsoft Way Redmond, WA 98052 United States of America Email: pamattes@microsoft.com

Dhanendra Jain 💅 Google Email: dhanendra.ietf@gmail.com

That's the whole RFC, bestie! 🎉🦋💖

📦 where this page comes from