RFC 9830

Advertising Segment Routing Policies in BGP

📅 published September 2025, from ietf

RFC 9830: Advertising Segment Routing Policies in BGP 🦋

okay bestie, this one is an IETF Standards Track doc from September 2025 (ISSN 2070-1721) and it's all about how BGP can carry Segment Routing Policies around the network 🌐✨. The authors are S. Previdi (Huawei Technologies), C. Filsfils, K. Talaulikar (Ed., Cisco Systems), P. Mattes (Microsoft), and D. Jain (Google) 🫶. The header only lists one relationship to another RFC: it updates RFC 9012 🔥. That's the big plot twist, and we'll get to it later.

Abstract 💜

okay so a Segment Routing (SR) Policy is an ordered list of segments (also called "instructions") that makes a source-routed policy 🛣️. Each SR Policy has one or more Candidate Paths (CPs), and each CP has one or more segment lists 📜. A headend can get these CPs through a bunch of different options: the Command-Line Interface (CLI), the Network Configuration Protocol (NETCONF), the Path Computation Element Communication Protocol (PCEP), or BGP 💅.

this doc says how BGP can be used to distribute SR Policy CPs 🚚. It adds a BGP SAFI for advertising a CP of an SR Policy, and it defines sub-TLVs for the Tunnel Encapsulation Attribute so these CPs can carry their info 🎀.

And the glow-up: this doc updates RFC 9012 by extending the Color Extended Community so it can support extra steering modes over SR Policy 🌈✨.

Status of This Memo 🌸

This is an Internet Standards Track document 🧚.

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

Info about the current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9830 💖.

Copyright Notice 💅

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 publication date 📜. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License ⚠️.

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  SR Policy Encoding
  2.1.  SR Policy SAFI and NLRI
  2.2.  SR Policy and Tunnel Encapsulation Attribute
  2.3.  Applicability of Tunnel Encapsulation Attribute Sub-TLVs
  2.4.  SR Policy Sub-TLVs
    2.4.1.  Preference Sub-TLV
    2.4.2.  Binding SID Sub-TLV
    2.4.3.  SRv6 Binding SID Sub-TLV
    2.4.4.  Segment List Sub-TLV
    2.4.5.  Explicit NULL Label Policy Sub-TLV
    2.4.6.  SR Policy Priority Sub-TLV
    2.4.7.  SR Policy Candidate Path Name Sub-TLV
    2.4.8.  SR Policy Name Sub-TLV
3.  Color Extended Community
4.  SR Policy Operations
  4.1.  Advertisement of SR Policies
  4.2.  Reception of an SR Policy NLRI
    4.2.1.  Validation of an SR Policy NLRI
    4.2.2.  Eligibility for Local Use of an SR Policy NLRI
    4.2.3.  Propagation of an SR Policy
5.  Error Handling and Fault Management
6.  IANA Considerations
  6.1.  Subsequent Address Family Identifiers (SAFI) Parameters
  6.2.  BGP Tunnel Encapsulation Attribute Tunnel Types
  6.3.  BGP Tunnel Encapsulation Attribute Sub-TLVs
  6.4.  Color Extended Community Flags
  6.5.  SR Policy Segment List Sub-TLVs
  6.6.  SR Policy Binding SID Flags
  6.7.  SR Policy SRv6 Binding SID Flags
  6.8.  SR Policy Segment Flags
  6.9.  Color Extended Community Color-Only Types
  6.10. SR Policy ENLP Values
7.  Security Considerations
8.  Manageability Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

okay so Segment Routing (SR) [RFC8402] lets a headend node steer a packet flow along a specific path 🛤️. Thanks to source routing, the intermediate per-path state just... disappears 🫧. Iconic.

The headend node is said to steer a flow into an SR Policy [RFC9256] 💖.

The packets steered into an SR Policy carry an ordered list of segments that's tied to that SR Policy 📦.

[RFC9256] goes deeper on the concepts of SR Policy and steering into an SR Policy 🧠. These apply equally to the SR-MPLS and Segment Routing over IPv6 (SRv6) data planes, which are the two flavors of Segment Routing that use SR-MPLS and SRv6 Segment Identifiers (SIDs) as described in [RFC8402] 🌈. [RFC8660] explains how that ordered list of segments gets represented and processed as an MPLS label stack for SR-MPLS 🏷️. [RFC8754] and [RFC8986] cover the same thing for SRv6, using the Segment Routing Header (SRH) 🎀.

The SR Policy stuff from [RFC9256] can be conceptually viewed as living inside an SR Policy Module (SRPM) 🧚‍♀️. Here's a quick reminder of what the SRPM does at a high level:

Learning multiple CPs for an SR Policy via various mechanisms (CLI, NETCONF, PCEP, or BGP).
Selecting the best CP for an SR Policy.
Associating a Binding SID (BSID) with the selected CP of an SR Policy.
Installing the selected CP and its BSID in the forwarding plane.

This document specifies how BGP distributes one or more of an SR Policy's CPs to the headend of that SR Policy 🚀. It describes what BGP does and, where it makes sense, points to references for the stuff that's outside BGP's scope (the stuff that lives in the SRPM on the headend node) 🙃.

This doc also defines a way to represent SR Policy CPs in BGP UPDATE messages 💌. BGP can then propagate those CPs to the headend nodes in a network 🌐. The usual BGP rules for propagation and best-path selection apply 👑. At the headend of a specific SR Policy, one or more CPs end up installed into the "BGP table" 📋. Those paths get passed to the SRPM 💅, which may compare them with CPs learned some other way and picks one or more to install in the data plane 🦋. BGP itself does not install SR Policy CPs into the data plane 🙅‍♀️.

This document introduces a BGP Subsequent Address Family Identifier (SAFI) for the IPv4 and IPv6 address families 💖. In BGP UPDATE messages for those AFI/SAFIs, the Network Layer Reachability Information (NLRI) identifies an SR Policy CP, and the attributes encode the segment lists and other details of that CP 📦✨.

Quick heads up: for simplicity this doc says BGP advertises an SR Policy, but it really means BGP advertises a CP of an SR Policy 🤓. That SR Policy might have several other CPs too, coming in via BGP (through an NLRI with a different distinguisher, as defined in Section 2.1), PCEP, NETCONF, or local policy configuration 🌸.

Usually an SR Policy Controller [RFC9256] defines the set of policies and advertises them to SR Policy headend routers (typically ingress routers) 🎯. These SR Policy advertisements use the BGP extensions defined in this document 💜. Most of the time the advertisement is tailored for one specific SR Policy headend, so it can go over a direct BGP session (no intermediate BGP hops) to that headend and doesn't get propagated any further 🙌. In those cases, SR Policy advertisements won't go through any Route Reflector (RR) (see [RFC4456] and Section 4.2.3) 🧚.

Another option: a BGP egress router may advertise SR Policies that represent paths terminating on it 🛬. In that case, the router can send these policies straight to each headend over a dedicated BGP session, with no further propagation needed 🎀.

Sometimes it's not ideal for a controller or BGP egress router to have a BGP session with every SR Policy headend 😩. In those situations, BGP RRs can be used to propagate the advertisements 🔁. In some other deployments, the advertisement might need to propagate through a sequence of one or more Autonomous Systems (ASes) inside an SR Domain (refer to Section 7 for the security considerations, and yes they're serious) 🚨. To make that possible, an attribute gets attached to the advertisement so a BGP speaker can tell whether it's supposed to be a headend for the advertised SR Policy 🔍. This is done by attaching one or more Route Target extended communities to the advertisement [RFC4360] 🎯.

The BGP extensions for advertising SR Policies include these pieces: - A SAFI whose NLRIs identify an SR Policy CP. - A Tunnel Type identifier for SR Policy, plus a set of sub-TLVs to go into the Tunnel Encapsulation Attribute (as defined in [RFC9012]). These carry the segment lists of the SR Policy CP and other info about the SR Policy. - One or more IPv4 address-specific format Route Target extended communities ([RFC4360]) attached to the SR Policy CP advertisement, showing which headend it's meant for.

The SR Policy SAFI route updates use the Tunnel Encapsulation Attribute to signal an SR Policy, which is itself acting as a tunnel 🚇. This is kinda different from [RFC9012], where the Tunnel Encapsulation Attribute is attached to a BGP route update (like for Internet or VPN routes) to say which tunnel traffic should use for forwarding 🌊. This doc doesn't change or replace how the Tunnel Encapsulation Attribute works for existing AFI/SAFIs as defined in [RFC9012] 🙅‍♀️. The details for how the SR Policy SAFI processes it are in Sections 2.2 and 2.3 🌟.

The northbound advertisement of SR Policy CP operational state, as part of BGP - Link State (BGP-LS) [RFC9552] topology info, is specified in [BGP-LS-SR-POLICY] 📡.

Signaling of Dynamic and Composite CPs (Sections 5.2 and 5.3, respectively, of [RFC9256]) is out of scope for this document 🙈.

The Color Extended Community (as defined in [RFC9012]) is used to steer traffic into an SR Policy, as described in Section 8.8 of [RFC9256] 🌈. Section 3 of this document updates [RFC9012] by changing the format of the Flags field of the Color Extended Community, using the two leftmost bits of that field 💅✨.

1.1. Requirements Language 🎀

okay 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 read as described in BCP 14 [RFC2119] [RFC8174] 📜. But only when they show up in all capitals, like they do here 🔠. Otherwise they're just regular words, bestie 🙃.

2. SR Policy Encoding 🦋

2.1. SR Policy SAFI and NLRI ✨

Okay bestie, the SR Policy SAFI with code point 73 is introduced right here 🎀 The AFI used MUST be IPv4(1) or IPv6(2). 💅

The SR Policy SAFI uses this NLRI format:

   +------------------+
   |  NLRI Length     | 1 octet
   +------------------+
   |  Distinguisher   | 4 octets
   +------------------+
   |  Color           | 4 octets
   +------------------+
   |  Endpoint        | 4 or 16 octets
   +------------------+

Figure 1: SR Policy SAFI Format

Here's the breakdown, no cap 🧚

NLRI Length: 1 octet giving the length in bits, as defined in [RFC4760]. When AFI = 1, the value MUST be 96. When AFI = 2, the value MUST be 192. 🍓
Distinguisher: a 4-octet value that uniquely identifies the SR Policy within the <Color, Endpoint> tuple. It has no semantic value of its own. The SR Policy originator uses it to form unique NLRIs in these situations:
- to tell apart multiple CPs of the same SR Policy
- to tell apart CPs meant for different headends that share the same Color and Endpoint

The distinguisher is the discriminator of the SR Policy CP, as specified in Section 2.5 of [RFC9256]. 🦋

Color: 4 octets carrying an unsigned non-zero integer, which gives the Color of the SR Policy as specified in Section 2.1 of [RFC9256]. The Color is what matches the Color of destination prefixes to steer traffic into the SR Policy, as specified in Section 8 of [RFC9256]. 🌈
Endpoint: a value identifying the Endpoint of an SR Policy. The Endpoint can stand for a single node or a whole set of nodes, like an anycast address. It's an IPv4 (4-octet) address or an IPv6 (16-octet) address, depending on the AFI of the NLRI. The address can be unicast, or it can be an unspecified address (0.0.0.0 for IPv4, :: for IPv6). That second kind is called a null Endpoint, as specified in Section 2.1 of [RFC9256]. ✨

The Color and Endpoint are used to automate steering of BGP service routes onto an SR Policy, as described in Section 8 of [RFC9256]. It's giving automation 🤖💖

The NLRI carrying an SR Policy CP travels in a BGP UPDATE message [RFC4271], using BGP multiprotocol extensions [RFC4760], with an AFI of 1 or 2 (IPv4 or IPv6) and a SAFI of 73. The fault management and error handling for the NLRI encoding are covered in Section 5. 🛡️

A BGP UPDATE message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI attribute with the SR Policy SAFI MUST also carry the BGP mandatory attributes. On top of that, the BGP UPDATE message MAY also contain any of the BGP optional attributes. 🫶

The next-hop network address field in SR Policy SAFI (73) updates may be either a 4-octet IPv4 address or a 16-octet IPv6 address, no matter what the SR Policy AFI is. The Length field of the next-hop address tells you which next-hop address family you're dealing with:

If the next-hop length is 4, the next-hop is an IPv4 address.
If the next-hop length is 16, it's a global IPv6 address.
If the next-hop length is 32, it has a global IPv6 address followed by a link-local IPv6 address.

Setting the next-hop field and handling it afterwards is governed by standard BGP procedures, as described in Section 3 of [RFC4760] and Section 3 of [RFC2545]. Standard procedures, zero drama 💅

It's really important that any BGP speaker receiving BGP updates with SR Policy NLRIs only processes the best path, using the BGP best-path selection algorithm. The SRPM does this. Basically, this document just rides on the existing BGP propagation and best-path selection rules. The details are in Section 4. 👑

It has to be noted that if several CPs of the same SR Policy (Endpoint, Color) are signaled via BGP to a headend, then it is RECOMMENDED that each NLRI uses a different distinguisher. 🎀 If BGP has installed two advertisements into the BGP table whose NLRIs share the same Color and Endpoint but have different distinguishers, both advertisements get passed to the SRPM as separate CPs. They come with their own originator information, meaning the Autonomous System Number (ASN) and the BGP Router-ID, as described in Section 2.4 of [RFC9256]. The ASN is the ASN of the origin. The BGP Router-ID is determined in this order:

From the Route Origin Community [RFC4360], if it's present and carries an IP Address, or
As the BGP ORIGINATOR_ID [RFC4456], if it's present, or
As the BGP Router-ID of the peer the update was received from, as a last resort. 🥲

Section 2.9 of [RFC9256] covers how the SRPM picks the active CP of the SR Policy, using the info BGP gives it. 🔥

2.2. SR Policy and Tunnel Encapsulation Attribute 🌸

The content of the SR Policy CP is encoded in the Tunnel Encapsulation Attribute defined in [RFC9012], using a Tunnel Type called the "SR Policy" type with code point 15. ✨ The SR Policy Tunnel Type only applies to the AFI/SAFI pairs (1/73, 2/73). This document specifies the Tunnel Encapsulation Attribute with the SR Policy Tunnel Type. Using any other Tunnel Type with the SR Policy SAFI MUST be considered malformed and handled by the "treat-as-withdraw" strategy [RFC7606]. Not it 🙅‍♀️

The SR Policy Encoding structure looks like this:

   SR Policy SAFI NLRI: <Distinguisher, Color, Endpoint>
   Attributes:
      Tunnel Encapsulation Attribute (23)
         Tunnel Type: SR Policy (15)
             Binding SID
             Preference
             Priority
             SR Policy Name
             SR Policy Candidate Path Name
             Explicit NULL Label Policy (ENLP)
             Segment List
                 Weight
                 Segment
                 Segment
                 ...
             ...

Figure 2: SR Policy Encoding

Where:

The SR Policy SAFI NLRI is defined in Section 2.1.
The Tunnel Encapsulation Attribute is defined in [RFC9012].
The Tunnel Type is set to 15.
Preference, Binding SID, Priority, SR Policy Name, SR Policy Candidate Path Name, ENLP, Segment-List, Weight, and Segment sub-TLVs are defined in Section 2.4.
More sub-TLVs may be defined in the future. 🔮

A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV of type "SR Policy". Updates like that MUST be considered malformed and handled by the "treat-as-withdraw" strategy [RFC7606]. Double SR Policy TLVs? Absolutely not 🙈

BGP doesn't need to validate the tunnel (aka the SR Policy) itself, as noted in Section 6 of [RFC9012]. The SRPM handles validation of the SR Policy info advertised through the sub-TLVs in Section 2.4. Everyone has their job 💜

2.3. Applicability of Tunnel Encapsulation Attribute Sub-TLVs 🦋

The Tunnel Egress Endpoint and Color sub-TLVs of the Tunnel Encapsulation Attribute, as defined in [RFC9012], aren't used for SR Policy encodings. So their values don't matter in the context of the SR Policy SAFI NLRI. If these sub-TLVs are present, a BGP speaker MUST ignore them and MAY remove them from the Tunnel Encapsulation Attribute during propagation. 🧹

Same vibe for any other sub-TLVs, including the ones specified in [RFC9012], that don't have an explicitly defined applicability to the SR Policy SAFI. A BGP speaker MUST ignore those, and they MAY be removed from the Tunnel Encapsulation Attribute during propagation. Bye bye, not your job 👋

2.4. SR Policy Sub-TLVs 🎀

This section specifies the sub-TLVs defined for encoding the info about the SR Policy Candidate Path. Let's gooo 🚀

Preference, Binding SID, SRv6 Binding SID, Segment-List, Priority, SR Policy Name, SR Policy Candidate Path Name, and Explicit NULL Label Policy are all OPTIONAL sub-TLVs. They're introduced for the BGP Tunnel Encapsulation Attribute [RFC9012] in this section. ✨

Weight and Segment are sub-TLVs of the Segment-List sub-TLV mentioned above. 🧩

An early draft of this document only had the Binding SID sub-TLV, which could be used for both SR-MPLS and SRv6 BSIDs. The SRv6 Binding SID TLV came in later versions. The point was to advertise extra SRv6 capabilities without breaking backward compatibility for early implementations. 🌈

The fault management and error handling for encoding the sub-TLVs in this section are specified in Section 5. For TLVs and sub-TLVs specified as single instance, only the first instance is used. The other instances MUST be ignored and MUST NOT be considered malformed. 🙈

None of the sub-TLVs defined in the following subsections have any effect on the BGP best-path selection or propagation procedures. The BGP path selection process doesn't use these sub-TLVs. Instead, they get passed on to the SRPM as SR Policy Candidate Path info for further processing, as described in Section 2 of [RFC9256]. 🫶

The use of SR Policy sub-TLVs only applies to the AFI/SAFI pairs (1/73, 2/73). Future documents may extend their applicability to other AFI/SAFI pairs. 🔮

2.4.1. Preference Sub-TLV 💖

The Preference sub-TLV carries the Preference of an SR Policy CP. The SRPM uses its contents as described in Section 2.7 of [RFC9256]. 👑

The Preference sub-TLV is OPTIONAL. It MUST NOT appear more than once in the SR Policy encoding. One is plenty bestie 💅

The Preference sub-TLV has this 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    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Preference (4 octets)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: Preference Sub-TLV

Where:

Type: 12
Length: The length of the value field in octets. That means not counting the Type and Length fields. The value MUST be 6. 📏
Flags: 1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt. 🚩
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt. 🌸
Preference: a 4-octet value giving the Preference of the SR Policy CP, as described in Section 2.7 of [RFC9256]. ⭐

2.4.2. Binding SID Sub-TLV 🎀

okay bestie, so the Binding SID sub-TLV 🦋 carries all the BSID-related info for an SR Policy CP ✨ The stuff in here gets used by the SRPM, as described in Section 6 of [RFC9256] 💅

The Binding SID sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding. so it's optional, but it can't show up twice, no cap 🙈

When this sub-TLV is signaling an SRv6 SID, the headend node is the one who picks which SRv6 Endpoint Behavior [RFC8986] gets instantiated 👑 It is RECOMMENDED that the SRv6 Binding SID sub-TLV, as defined in Section 2.4.3, be used when signaling an SRv6 BSID for an SR Policy CP. Using this Binding SID sub-TLV for SRv6 BSIDs is only kept around mainly for backward compatibility 🥺 It's for implementations that followed early draft versions of this document, back when the SRv6 Binding SID sub-TLV wasn't defined yet.

The Binding SID sub-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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Binding SID (variable, optional)                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: Binding SID Sub-TLV

Where:

Type: 13 🌸

Length: This is the length of the value field (so not counting the Type and Length fields), measured in octets. The value MUST be 18 when a SRv6 BSID is present, 6 when an SR-MPLS BSID is present, or 2 when no BSID is present.

Flags: 1 octet of flags. The following flags are defined in the registry "SR Policy Binding SID Flags" as described in Section 6.6:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I|           |
+-+-+-+-+-+-+-+-+

Figure 5: SR Policy Binding SID Flags

Where:

The S-Flag encodes the "Specified-BSID-Only" behavior. SRPM uses it as described in Section 6.2.3 of [RFC9256].
The I-Flag encodes the "Drop-Upon-Invalid" behavior. SRPM uses it as described in Section 8.2 of [RFC9256] to define a specific SR Policy forwarding behavior. The flag says the SR Policy should do "Drop-Upon-Invalid" when no valid CP is available for it. In that case, the CP with the highest preference among those with the "Drop-Upon-Invalid" behavior becomes active, so it drops the traffic steered over the SR Policy 🫶
The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.

RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.

Binding SID: If the length is 2, then no BSID is present. If the length is 6, then the BSID is encoded in 4 octets using the format below. The Traffic Class (TC), S, and TTL (12 bits total) are RESERVED, and they MUST be set to zero and MUST be ignored.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 6: Binding SID Label Encoding

The Label field is validated by the SRPM, but it MUST NOT contain the reserved MPLS label values (0-15). If the length is 18, then the BSID contains a 16-octet SRv6 SID.

2.4.3. SRv6 Binding SID Sub-TLV 🦋

The SRv6 Binding SID sub-TLV carries the SRv6-BSID-related info for an SR Policy CP ✨ It lets you specify the SRv6 Endpoint Behavior [RFC8986] that should be instantiated on the headend node. The SRPM uses the contents of this sub-TLV as described in Section 6 of [RFC9256] 💖

The SRv6 Binding SID sub-TLV is OPTIONAL. More than one SRv6 Binding SID sub-TLV MAY be signaled in the same SR Policy encoding, so you can indicate one or more SRv6 SIDs, each with potentially different SRv6 Endpoint Behaviors to be instantiated 🌈

The SRv6 Binding SID sub-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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 SRv6 Binding SID (16 octets)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//     SRv6 Endpoint Behavior and SID Structure (optional)     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: SRv6 Binding SID Sub-TLV

Where:

Type: 20

Length: This is the length of the value field (so not counting the Type and Length fields), measured in octets. The value MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is present; otherwise, it MUST be 18.

Flags: 1 octet of flags. The following flags are defined in the registry "SR Policy SRv6 Binding SID Flags" as described in Section 6.7:

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

Figure 8: SR Policy SRv6 Binding SID Flags

Where:

The S-Flag encodes the "Specified-BSID-Only" behavior. SRPM uses it as described in Section 6.2.3 of [RFC9256].
The I-Flag encodes the "Drop-Upon-Invalid" behavior. SRPM uses it as described in Section 8.2 of [RFC9256].
The B-Flag, when set, indicates that the "SRv6 Endpoint Behavior & SID Structure" encoding from Section 2.4.4.2.4 is present ✨
The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.

RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.

SRv6 Binding SID: Contains a 16-octet SRv6 SID. The value 0 MAY be used when the controller wants to indicate the desired SRv6 Endpoint Behavior, SID Structure, or flags without specifying the BSID 🧚

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

2.4.4. Segment List Sub-TLV 💜

The Segment List sub-TLV encodes a single explicit path toward the Endpoint, as described in Section 5.1 of [RFC9256] 🛤️ It includes the elements of the path (the segments) plus an optional Weight sub-TLV.

The Segment List sub-TLV may be more than 255 bytes long because it can hold a lot of segments, so a 2-octet length is required. According to Section 2 of [RFC9012], the sub-TLV type decides how big the Length field is. That's why the Segment List sub-TLV uses a code point of 128 or higher 🙌

The Segment List sub-TLV is OPTIONAL and MAY appear multiple times in the SR Policy encoding. The order of Segment List sub-TLVs doesn't matter, since each one encodes its own Segment List 🍓

The Segment List sub-TLV contains zero or more Segment sub-TLVs and MAY contain a Weight sub-TLV.

The Segment List sub-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            |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                           sub-TLVs                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Segment List Sub-TLV

Where:

Type: 128

Length: The total length (not counting the Type and Length fields) of the sub-TLVs inside the Segment List sub-TLV, measured in octets.

RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.

sub-TLVs currently defined:

An optional single Weight sub-TLV
Zero or more Segment sub-TLVs

Validating the explicit path encoded by the Segment List sub-TLV is outside the scope of BGP. The SRPM does that, as described in Section 5 of [RFC9256] 🔍

2.4.4.1. Weight Sub-TLV 🍬

The Weight sub-TLV specifies the weight for a given segment list. Only the SRPM uses its contents, as described in Section 2.11 of [RFC9256] ⭐

The Weight sub-TLV is OPTIONAL; it MUST NOT appear more than once inside the Segment List sub-TLV.

The Weight sub-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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              Weight                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Weight Sub-TLV

Where:

Type: 9

Length: This is the length of the value field (so not counting the Type and Length fields), measured in octets. The value MUST be 6.

Flags: 1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.

RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.

Weight: 4 octets carrying an unsigned integer that gives the weight for a segment list, as described in Section 2.11 of [RFC9256]. A weight value of zero is invalid 🚫

2.4.4.2. Segment Sub-TLVs 🎀✨

okay so bestie, a Segment sub-TLV describes ONE single segment inside a segment list 🦋 (aka one element of the explicit path). You can have one or more Segment sub-TLVs, and together they make up the explicit path of the SR Policy CP 💅. The contents of these sub-TLVs are only used by the SRPM, as described in Section 4 of [RFC9256] 🫶.

The Segment sub-TLVs are OPTIONAL, and they MAY show up multiple times in the Segment List sub-TLV 🌸.

Section 4 of [RFC9256] defines several Segment Types. Here they are, 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

The following subsections specify the sub-TLVs used for Segment Types A and B 🧚. The other segment types are specified in [RFC9831] 💜. As specified in Section 5.1 of [RFC9256], a mix of SR-MPLS and SRv6 segments makes the segment-list invalid 💀.

2.4.4.2.1. Segment Type A 🌈

okay so the Type A Segment sub-TLV encodes a single SR-MPLS SID 🦋. The format is below, and it's used to encode MPLS Label fields as specified in [RFC3032] and [RFC5462] ✨:

 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label                        | TC  |S|       TTL     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Type A Segment Sub-TLV

Here's what each bit means, bestie 🎀:

Type: 1
Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 6.
Flags: 1 octet of flags as defined in Section 2.4.4.2.3.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Label: 20 bits of label value.
TC: 3 bits of traffic class.
S: 1 bit of bottom-of-stack.
TTL: 1 octet of TTL.

The following applies to the Type-1 Segment sub-TLV, no cap 💅:

The S bit MUST be zero upon transmission and MUST be ignored upon reception.
If the originator wants the receiver to choose the TC value, it sets the TC field to zero.
If the originator wants the receiver to choose the TTL value, it sets the TTL field to 255.
If the originator wants to recommend a value for these fields, it puts those values in the TC and/or TTL fields.
The receiver MAY override the originator's values for these fields. This would be determined by local policy at the receiver. One possible policy would be to override the fields only if the fields have the default values specified above 🙈.

2.4.4.2.2. Segment Type B 🍓

okay so the Type B Segment sub-TLV encodes a single SRv6 SID ✨. The format is as follows 🧚:

 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                       SRv6 SID (16 octets)                  //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//           SRv6 Endpoint Behavior and SID Structure          //
//                    (optional, 8 octets)                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 12: Type B Segment Sub-TLV

Where, bestie 🌸:

Type: 13
Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 26 when the SRv6 Endpoint Behavior and SID Structure is present; else, it MUST be 18.
Flags: 1 octet of flags as defined in Section 2.4.4.2.3.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
SRv6 SID: 16 octets of IPv6 address.
SRv6 Endpoint Behavior and SID Structure: Optional, as defined in Section 2.4.4.2.4. The SRv6 Endpoint Behavior and SID Structure MUST NOT be included when the SRv6 SID has not been included.

The sub-TLV code point 2 defined for the advertisement of Segment Type B in the earlier draft versions of this document has been deprecated to avoid backward compatibility issues 🥺.

2.4.4.2.3. SR Policy Segment Flags 🦋

The Segment Type sub-TLVs described above may contain the following SR Policy Segment Flags in their Flags field. Also refer to Section 6.8 👑:

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

Figure 13: SR Policy Segment Flags

Where, bestie 💖:

When the V-Flag is set, it is used by SRPM for "SID verification" as described in Section 5.1 of [RFC9256].
When the B-Flag is set, it indicates the presence of the "SRv6 Endpoint Behavior & SID Structure" encoding specified in Section 2.4.4.2.4.
The unassigned bits in the Flags field MUST be set to zero upon transmission and MUST be ignored upon receipt.

The following applies to the Segment Flags, periodt ✨:

V-Flag applies to all Segment Types.
B-Flag applies to Segment Type B. If B-Flag appears with Segment Type A, it MUST be ignored.

2.4.4.2.4. SRv6 Endpoint Behavior and SID Structure 🧚

The Segment Type sub-TLVs described above MAY contain the SRv6 Endpoint Behavior and SID Structure [RFC8986] encoding as described below 💅:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Endpoint Behavior       |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14: SRv6 Endpoint Behavior and SID Structure

Where, bestie 🫶:

Endpoint Behavior: 2 octets. It carries the SRv6 Endpoint Behavior code point for this SRv6 SID as defined in Section 10.2 of [RFC8986]. When set with the value 0xFFFF (i.e., Opaque), the choice of SRv6 Endpoint Behavior is left to the headend.
Reserved: 2 octets of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
Locator Block Length: 1 octet. SRv6 SID Locator Block length in bits.
Locator Node Length: 1 octet. SRv6 SID Locator Node length in bits.
Function Length: 1 octet. SRv6 SID Function length in bits.
Argument Length: 1 octet. SRv6 SID Arguments length in bits.

The total of the locator block, locator node, function, and argument lengths MUST be less than or equal to 128 👑.

2.4.5. Explicit NULL Label Policy Sub-TLV 🌈

okay so, to steer an unlabeled IP packet into an SR Policy for the MPLS data plane, you have to push a label stack of one or more labels onto that packet 🦋.

The Explicit NULL Label Policy (ENLP) sub-TLV is used to indicate whether an Explicit NULL Label [RFC3032] MUST be pushed on an unlabeled IP packet before any other labels 🎀.

If an ENLP sub-TLV is not present, the decision of whether to push an Explicit NULL label on a given packet is a matter of local configuration ✨.

The ENLP sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding 💜.

The contents of this sub-TLV are used by the SRPM as described in Section 4.1 of [RFC9256] 🧚.

 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ENLP      |
+-+-+-+-+-+-+-+-+

Figure 15: ENLP Sub-TLV

Where, bestie 🍓:

Type: 14
Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 3.
Flags: 1 octet of flags. No flags are defined in this document. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
ENLP (Explicit NULL Label Policy): Indicates whether Explicit NULL labels are to be pushed on unlabeled IP packets that are being steered into a given SR Policy. The following values have been currently defined for this field:
- 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet but do not push an IPv6 Explicit NULL label on an unlabeled IPv6 packet.
- 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 packet but do not push an IPv4 Explicit NULL label on an unlabeled IPv4 packet.
- 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 packet and push an IPv6 Explicit NULL label on an unlabeled IPv6 packet.
- 4: Do not push an Explicit NULL label.

This field can have one of the values as specified in Section 6.10. The ENLP unassigned values MAY be used for future extensions. Implementations adhering to this document MUST ignore the ENLP sub-TLV with unrecognized values (viz. other than 1 through 4). The behavior signaled in this sub-TLV MAY be overridden by local configuration by the network operator based on their deployment requirements. Section 4.1 of [RFC9256] describes the behavior on the headend for the handling of the Explicit NULL label 🫶.

2.4.6. SR Policy Priority Sub-TLV 💅

An operator MAY set the SR Policy Priority sub-TLV to indicate the order in which the SR policies are recomputed upon topological change 🌸. The contents of this sub-TLV are used by the SRPM as described in Section 2.12 of [RFC9256] ✨.

The Priority sub-TLV is OPTIONAL; it MUST NOT appear more than once in the SR Policy encoding 🦋.

The Priority sub-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      |  Priority     |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Priority Sub-TLV

Where, bestie 👑:

Type: 15
Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 2.
Priority: A 1-octet value indicating the priority as specified in Section 2.12 of [RFC9256].
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.

2.4.7. SR Policy Candidate Path Name Sub-TLV 🏷️

okay so an operator MAY set the SR Policy Candidate Path Name sub-TLV to slap a symbolic name onto the SR Policy CP ✨

How it gets used is covered in Section 2.6 of [RFC9256], so go check there for the full scoop 💅

This sub-TLV can go past 255 bytes if the name is long, so it needs a 2-octet length. Per Section 2 of [RFC9012], the sub-TLV type decides how big the Length field is, which is why this one gets a code point of 128 or higher 🌸

It is RECOMMENDED that the name be kept to 255 bytes 💖 Implementations MAY truncate longer names to 255 bytes when they send them over BGP.

The SR Policy Candidate Path Name sub-TLV is OPTIONAL, and it MUST NOT show up more than once in the SR Policy encoding 🎀

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                      |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//            SR Policy Candidate Path Name                     //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 17: SR Policy Candidate Path Name Sub-TLV

Here's what each bit means:

Type: 129
Length: the length of the value field in octets (so not counting the Type and Length fields). It's variable 🧚
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
SR Policy Candidate Path Name: the symbolic name for the SR Policy CP, with no NULL terminator, encoded as described in Section 2.6 of [RFC9256].

2.4.8. SR Policy Name Sub-TLV 🦋

An operator MAY set the SR Policy Name sub-TLV to link a symbolic name to the SR Policy whose CP is being advertised through the SR Policy NLRI 🌈

Its usage is described in Section 2.1 of [RFC9256].

Long SR Policy names can push this sub-TLV past 255 bytes, so again a 2-octet length is needed. According to Section 2 of [RFC9012], the sub-TLV type sets the Length field size, so this one uses a code point of 128 or higher 💜

It is RECOMMENDED that the name be limited to 255 bytes. Implementations MAY truncate long names to 255 bytes when signaling via BGP 🍓

The SR Policy Name sub-TLV is OPTIONAL, and it MUST NOT appear more than once in the SR Policy encoding 🙈

The format 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                      |   RESERVED    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                      SR Policy Name                          //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 18: SR Policy Name Sub-TLV

The breakdown:

Type: 130
Length: the length of the value field in octets, not including Type and Length. It's variable.
RESERVED: 1 octet of reserved bits. This field MUST be set to zero on transmission and MUST be ignored on receipt.
SR Policy Name: the symbolic name for the SR Policy, with no NULL terminator, encoded as specified in Section 2.1 of [RFC9256] ✨

3. Color Extended Community 🌷

The Color Extended Community [RFC9012] is how you steer traffic from BGP routes into an SR Policy with a matching Color value 🚦 The Color Extended Community MAY ride along in any BGP UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6 Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast), 1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast), or 25/70 (Ethernet VPN, usually known as EVPN). Using the Color Extended Community in UPDATE messages for other AFI/SAFIs isn't covered by [RFC9012], so it's out of scope for this document too 🙅‍♀️

Two bits in the Flags field of the Color Extended Community are used to support the Color-Only steering requirements from Section 8.8 of [RFC9256] 💅

                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C O|        Unassigned         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 19: Color Extended Community Flags

The C and O bits together make up the Color-Only Type field. It tells you which matching criteria apply between the BGP Next Hop (NH) and the SR Policy Endpoint, on top of matching the Color value 👑 These types are defined:

Type 0 (bits 00): Specific Endpoint Match. Asks for a match on the Endpoint that is the BGP NH.
Type 1 (bits 01): Specific or Null Endpoint Match. Asks for a match on either the Endpoint that is the BGP NH or a null Endpoint (e.g., a default gateway).
Type 2 (bits 10): Specific, Null, or Any Endpoint Match. Asks for a match on either the Endpoint that is the BGP NH or a null or any Endpoint.
Type 3 (bits 11): Reserved for future use, and SHOULD NOT be used. Upon reception, an implementation MUST treat it like Type 0. 😭

The details of how SR Policy steering works with these Color-Only types are in Section 8.8 of [RFC9256] 🫶

One or more Color Extended Communities MAY be associated with a BGP route update. Sections 8.4.1, 8.5.1, and 8.8.2 of [RFC9256] describe how steering works over SR Policies when a BGP route has multiple Color Extended Communities attached 🌸

4. SR Policy Operations 🎀

As mentioned in Section 1, BGP is not the actual consumer of an SR Policy NLRI. BGP handles originating and propagating the SR Policy NLRI, but installing and using the policy is outside the scope of BGP. The details of SR Policy installation and use are specified in [RFC9256] 🧚

4.1. Advertisement of SR Policies 📣

Typically, though not only, an SR Policy is computed by a controller or a Path Computation Engine (PCE), and a BGP speaker originates it on that entity's behalf 💜

Multiple SR Policy NLRIs may show up with the same <Color, Endpoint> tuple, but with different distinguishers, when those SR Policies are meant for different headends 🦋

The distinguisher on each SR Policy NLRI stops unwanted BGP route selection among these NLRIs, and it lets them travel across RRs [RFC4456] 💖

On top of that, one or more route targets SHOULD be attached to the advertisement, where each route target identifies one or more intended headends for the advertised SR Policy update ✨

If no route target is attached to the SR Policy NLRI, then the originator is assumed to send the SR Policy update directly (e.g., through a BGP session) to the intended receiver. In that case, the NO_ADVERTISE community [RFC1997] MUST be attached to the SR Policy update (more details in Section 4.2.3) 🙈

4.2. Reception of an SR Policy NLRI 📬

When a BGP speaker gets an SR Policy NLRI, it first checks whether the NLRI is valid, as described in Section 4.2.1. Then it runs the decision process for selecting the best route (Section 9.1 of [RFC4271]). The key difference from the base BGP decision process is that BGP does not download the selected best routes of the SR Policy SAFI into the forwarding plane. Instead, it considers them "usable" so they can be passed on to the SRPM for further processing, as described in Section 4.2.2. The selected best route is "propagated" (Section 9.1.3 of [RFC4271]) as described in Section 4.2.3, whether or not the local router can actually use it 🌈

4.2.1. Validation of an SR Policy NLRI 🔍

When a BGP speaker receives an SR Policy NLRI from a neighbor, it MUST first validate it using the following rules, on top of the validation described in Section 5 💅

The SR Policy NLRI MUST include a distinguisher, Color, and Endpoint field, which implies that the length of the NLRI MUST be either 12 or 24 octets (depending on the address family of the Endpoint). 🎀
The SR Policy update MUST have either the NO_ADVERTISE community, at least one Route Target extended community in IPv4-address format, or both. If a router supporting this specification receives an SR Policy update with no Route Target extended communities and no NO_ADVERTISE community, the update MUST be considered malformed 🙅‍♀️
The Tunnel Encapsulation Attribute MUST be attached to the BGP UPDATE message, and it MUST have a Tunnel Type TLV set to SR Policy (code point is 15) 🧚

A router that gets an SR Policy update that isn't valid under these criteria MUST treat the update as malformed, and the SR Policy CP MUST NOT be passed to the SRPM 😭

4.2.2. Eligibility for Local Use of an SR Policy NLRI 🦋

An SR Policy NLRI update that has no Route Target extended community but does have the NO_ADVERTISE community is considered usable ✨

If one or more route targets are present, then at least one route target MUST match the BGP Identifier of the receiver for the update to be considered usable. The BGP Identifier is defined in [RFC4271] as a 4-octet IPv4 address, and [RFC6286] updates it to a 4-octet, unsigned, non-zero integer. Therefore, the Route Target extended community MUST be of the same format 🔥

If one or more route targets are present, and none of them matches the local BGP Identifier, then, even though the SR Policy NLRI is valid, it is not usable on the receiver node 💀

When the SR Policy tunnel type includes any sub-TLV that is unrecognized or unsupported, the update SHOULD NOT be considered usable. An implementation MAY provide an option for ignoring unsupported sub-TLVs 🌸

Once BGP on the receiving node decides the SR Policy NLRI is usable, it passes the SR Policy CP to the SRPM. BGP also passes along the originator information, which is used for breaking ties in the CP selection process as described in Section 2.4 of [RFC9256] 👑

When an update for an SR Policy NLRI makes it unusable, BGP MUST delete the corresponding SR Policy CP from the SRPM 🫶

The SRPM applies the rules in Section 2 of [RFC9256] to decide whether the SR Policy CP is valid and to select the active CP for a given SR Policy 💖

4.2.3. Propagation of an SR Policy 🦋

okay so SR Policy NLRIs with the NO_ADVERTISE community attached are MUST NOT propagated, no exceptions 🙅‍♀️

by default, a BGP node that gets an SR Policy NLRI MUST NOT pass it on to any External BGP (EBGP) neighbor 🚫 bestie, that's the default. an implementation MAY give you explicit config to override this and turn on propagation of valid SR Policy NLRIs to specific EBGP neighbors, but only where the SR domain spans multiple ASes inside a single service provider domain (see Section 7 for details) 🌐✨

a BGP node advertises a received SR Policy NLRI to its Internal BGP (IBGP) neighbors following the normal IBGP propagation rules 💜

by default, a BGP node that receives an SR Policy NLRI SHOULD NOT remove the Route Target extended community before propagating it 🎀 an implementation MAY offer configuration to filter and/or remove the Route Target extended community before propagation, so you've got options 💅

and the big one: a BGP node MUST NOT alter the SR Policy information carried in the Tunnel Encapsulation Attribute during propagation. hands off the tunnel encapsulation data, it's giving untouchable 🫶😭

5. Error Handling and Fault Management 💀

this section covers the error-handling actions from [RFC7606] that you need to perform when handling BGP UPDATE messages for the BGP SR Policy SAFI 🧚

first up, a BGP speaker MUST perform the following syntactic validation of the SR Policy NLRI to figure out if it's malformed. that includes checking the length of each NLRI and the total length of the MP_REACH_NLRI and MP_UNREACH_NLRI attributes. it also means checking that the NLRI length is consistent with the AFI and the endpoint address, as specified in Section 2.1 🔍

now, when the error lets the router skip the malformed NLRI(s) and keep going with the rest of the BGP UPDATE message, the router MUST handle those malformed NLRIs as "treat-as-withdraw" 🌸

but if the NLRI encoding error means the router can't process the BGP UPDATE message at all (e.g., length-related encoding errors), then the router SHOULD handle those malformed NLRIs as "AFI/SAFI disable" when other AFI/SAFIs besides SR Policy are advertised over the same session 😩 alternately, the router MUST perform "session reset" when the session is only being used for SR Policy, or when an "AFI/SAFI disable" action isn't possible. no escape, periodt 🔥

next, the TLVs/sub-TLVs introduced in this document and defined in their respective subsections of Section 2.4 MUST be validated to see if they're malformed or invalid 💖 the Tunnel Encapsulation Attribute itself, plus the other TLVs/sub-TLVs specified in Section 13 of [RFC9012], MUST be validated as described in that document 🦋 if any error is detected, whether at the attribute level or the TLV/sub-TLV level, the "treat-as-withdraw" strategy MUST be applied. why? because an SR Policy update without a valid Tunnel Encapsulation Attribute (made up of all valid TLVs/sub-TLVs) is not usable. it's giving all-or-nothing 🍓

an SR Policy update that is determined to be invalid (and therefore malformed) based on the rules in Section 4.2.1 MUST be handled by the "treat-as-withdraw" strategy too 🙈

and the individual fields inside the TLVs/sub-TLVs defined in Section 2.4 are out of BGP's lane. they're handled by the SRPM, as described in each TLV/sub-TLV subsection 🧚‍♀️ so a BGP implementation MUST NOT perform semantic verification of those fields, nor consider the SR Policy update invalid or unusable based on such validation. not your job, bestie 💅

finally, an implementation SHOULD log any errors found during the validation above so they can be analyzed later 📝✨

6. IANA Considerations 🌈

this document uses code point allocations from the following existing registries in the "Subsequent Address Family Identifiers (SAFI) Parameters" registry group:

The "SAFI Values" registry

this document also uses code point allocations from the following existing registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group:

The "BGP Tunnel Encapsulation Attribute Tunnel Types" registry
The "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry
The "Color Extended Community Flags" registry

this document creates the following new registries in the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group:

The "SR Policy Segment List Sub-TLVs" registry
The "SR Policy Binding SID Flags" registry
The "SR Policy SRv6 Binding SID Flags" registry
The "SR Policy Segment Flags" registry
The "Color Extended Community Color-Only Types" registry

this document creates the following new registry in the "Segment Routing" registry group:

The "SR Policy ENLP Values" registry

6.1. Subsequent Address Family Identifiers (SAFI) Parameters 🧁

this document registers a SAFI code point in the "SAFI Values" registry of the "Subsequent Address Family Identifiers (SAFI) Parameters" registry group, like so:

                  +=======+================+===========+
                  | Value | Description    | Reference |
                  +=======+================+===========+
                  | 73    | SR Policy SAFI | RFC 9830  |
                  +-------+----------------+-----------+

                       Table 1: BGP SAFI Code Point

6.2. BGP Tunnel Encapsulation Attribute Tunnel Types 🎀

this document registers a Tunnel Type code point in the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group.

                    +=======+=============+===========+
                    | Value | Description | Reference |
                    +=======+=============+===========+
                    | 15    | SR Policy   | RFC 9830  |
                    +-------+-------------+-----------+

                      Table 2: Tunnel Type Code Point

6.3. BGP Tunnel Encapsulation Attribute Sub-TLVs 🦄

this document defines sub-TLVs in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. so many sub-TLVs, so many vibes 🌟

   +=======+==========================+===========+===================+
   | Value | Description              | Reference | Change Controller |
   +=======+==========================+===========+===================+
   | 12    | Preference sub-TLV       | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 13    | Binding SID sub-TLV      | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 14    | ENLP sub-TLV             | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 15    | Priority sub-TLV         | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 20    | SRv6 Binding SID sub-TLV | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 128   | Segment List sub-TLV     | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+
   | 129   | SR Policy Candidate Path | RFC 9830  | IETF              |
   |       | Name sub-TLV             |           |                   |
   +-------+--------------------------+-----------+-------------------+
   | 130   | SR Policy Name sub-TLV   | RFC 9830  | IETF              |
   +-------+--------------------------+-----------+-------------------+

     Table 3: BGP Tunnel Encapsulation Attribute Sub-TLV Code Points

6.4. Color Extended Community Flags 🌸

this document defines the use of 2 bits in the "Color Extended Community Flags" registry under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. tiny but mighty 💜

           +==============+========================+===========+
           | Bit Position | Description            | Reference |
           +==============+========================+===========+
           | 0-1          | Color-only Types Field | RFC 9830  |
           +--------------+------------------------+-----------+

                Table 4: Color Extended Community Flag Bits

6.5. SR Policy Segment List Sub-TLVs 🍓

this document creates a new registry called "SR Policy Segment List Sub-TLVs" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. the registration policy for this registry is "IETF Review" (see [RFC8126]) 📜

the following initial sub-TLV code points are assigned by this document:

              +========+========================+===========+
              | Value  | Description            | Reference |
              +========+========================+===========+
              | 0      | Reserved               | RFC 9830  |
              +--------+------------------------+-----------+
              | 1      | Type A Segment sub-TLV | RFC 9830  |
              +--------+------------------------+-----------+
              | 2      | Deprecated             | RFC 9830  |
              +--------+------------------------+-----------+
              | 3-8    | Unassigned                         |
              +--------+------------------------+-----------+
              | 9      | Weight sub-TLV         | RFC 9830  |
              +--------+------------------------+-----------+
              | 10     | Deprecated             | RFC 9830  |
              +--------+------------------------+-----------+
              | 11     | Deprecated             | RFC 9830  |
              +--------+------------------------+-----------+
              | 12     | Deprecated             | RFC 9830  |
              +--------+------------------------+-----------+
              | 13     | Type B Segment sub-TLV | RFC 9830  |
              +--------+------------------------+-----------+
              | 14-255 | Unassigned                         |
              +--------+------------------------------------+

                  Table 5: SR Policy Segment List Sub-TLV
                                Code Points

6.6. SR Policy Binding SID Flags 🦋

this document creates a new registry called "SR Policy Binding SID Flags" under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group. the registration policy for this registry is "Standards Action" (see [RFC8126]) ✨

the following flags are defined:

       +=====+===================================+===========+
       | Bit | Description                       | Reference |
       +=====+===================================+===========+
       | 0   | Specified-BSID-Only Flag (S-Flag) | RFC 9830  |
       +-----+-----------------------------------+-----------+
       | 1   | Drop-Upon-Invalid Flag (I-Flag)   | RFC 9830  |
       +-----+-----------------------------------+-----------+
       | 2-7 | Unassigned                                    |
       +-----+-----------------------------------------------+

                    Table 6: SR Policy Binding SID Flags

6.7. SR Policy SRv6 Binding SID Flags 🎀

okay so bestie, this registry is giving organized chaos in the best way ✨ It's called "SR Policy SRv6 Binding SID Flags" and it lives under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" registry group 🌸 The registration policy is "Standards Action" (see [RFC8126]), which means it's the big-deal, careful-review kind of entry 💅

Here are the flags that got defined, and yes they're all from RFC 9830 🦋

+=====+===================================+===========+
| Bit | Description                       | Reference |
+=====+===================================+===========+
| 0   | Specified-BSID-Only Flag (S-Flag) | RFC 9830  |
+-----+-----------------------------------+-----------+
| 1   | Drop-Upon-Invalid Flag (I-Flag)   | RFC 9830  |
+-----+-----------------------------------+-----------+
| 2   | SRv6 Endpoint Behavior & SID      | RFC 9830  |
|     | Structure Flag (B-Flag)           |           |
+-----+-----------------------------------+-----------+
| 3-7 | Unassigned                                    |
+-----+-----------------------------------------------+

Table 7: SR Policy SRv6 Binding SID Flags 💜

6.8. SR Policy Segment Flags 🌈

next up, the segment flags registry 🫶 This one is also under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" group, called "SR Policy Segment Flags" 💖 The registration policy here is "IETF Review" (see [RFC8126]), which is a little more chill than Standards Action but still a real process 🍓

The flags are:

+=====+====================================+===========+
| Bit | Description                        | Reference |
+=====+====================================+===========+
| 0   | Segment Verification Flag (V-Flag) | RFC 9830  |
+-----+------------------------------------+-----------+
| 1-2 | Unassigned                                     |
+-----+------------------------------------+-----------+
| 3   | SRv6 Endpoint Behavior & SID       | RFC 9830  |
|     | Structure Flag (B-Flag)            |           |
+-----+------------------------------------+-----------+
| 4-7 | Unassigned                                     |
+-----+------------------------------------------------+

Table 8: SR Policy Segment Flags 🔥

6.9. Color Extended Community Color-Only Types 👑

this registry is giving "small but mighty" vibes ✨ It's called "Color Extended Community Color-Only Types", also under the "Border Gateway Protocol (BGP) Tunnel Encapsulation" group 🦋 It's for assigning code points (values 0 through 3) in the Color-Only Type field of the Color Extended Community Flags field 🎀 The registration policy is "Standards Action" (see [RFC8126]), so again, serious business 💅

The types that were defined:

+======+=======================================+===========+
| Type | Description                           | Reference |
+======+=======================================+===========+
| 0    | Specific Endpoint Match               | RFC 9830  |
+------+---------------------------------------+-----------+
| 1    | Specific or Null Endpoint Match       | RFC 9830  |
+------+---------------------------------------+-----------+
| 2    | Specific, Null, or Any Endpoint Match | RFC 9830  |
+------+---------------------------------------+-----------+
| 3    | Unassigned                            | RFC 9830  |
+------+---------------------------------------+-----------+

Table 9: Color Extended Community Color-Only Types 🧚

6.10. SR Policy ENLP Values 🌸

last IANA bit, and it's a good one 🙈 IANA will maintain a new registry under the "Segment Routing" registry group, with the registration policy "Standards Action" (see [RFC8126]) 💜 It's called "SR Policy ENLP Values" and holds the code points allocated to the ENLP field defined in Section 2.4.5 ✨ The registry contains these code points:

+=======+===================================+===========+
| Code  | Description                       | Reference |
| Point |                                   |           |
+=======+===================================+===========+
| 0     | Reserved                          | RFC 9830  |
+-------+-----------------------------------+-----------+
| 1     | Push an IPv4 Explicit NULL label  | RFC 9830  |
|       | on an unlabeled IPv4 packet but   |           |
|       | do not push an IPv6 Explicit NULL |           |
|       | label on an unlabeled IPv6 packet |           |
+-------+-----------------------------------+-----------+
| 2     | Push an IPv6 Explicit NULL label  | RFC 9830  |
|       | on an unlabeled IPv6 packet but   |           |
|       | do not push an IPv4 Explicit NULL |           |
|       | label on an unlabeled IPv4 packet |           |
+-------+-----------------------------------+-----------+
| 3     | Push an IPv6 Explicit NULL label  | RFC 9830  |
|       | on an unlabeled IPv6 packet and   |           |
|       | push an IPv4 Explicit NULL label  |           |
|       | on an unlabeled IPv4 packet       |           |
+-------+-----------------------------------+-----------+
| 4     | Do not push an Explicit NULL      | RFC 9830  |
|       | label                             |           |
+-------+-----------------------------------+-----------+
| 5-255 | Unassigned                                    |
+-------+-----------------------------------------------+

Table 10: SR Policy ENLP Values 🦋

7. Security Considerations 🔥

okay bestie, this part is SERIOUS 😭 The base BGP security model applies to the extensions in this document too 💀 For BGP security discussion, see the Security Considerations section of [RFC4271] ✨ You should also refer to [RFC4272] and [RFC6952] for analysis of BGP security issues 🫶

The BGP SR Policy extensions here enable traffic engineering and service programming use cases within an SR domain, as described in [RFC9256] 🌈 SR operates within a trusted SR domain [RFC8402], and its security considerations also apply to BGP sessions carrying SR Policy information 💅 The SR Policies distributed by BGP are expected to be used entirely within this trusted SR domain. That domain can be a single AS, or multiple ASes / domains within a single provider network 👑 So precaution is necessary to make sure SR Policy information advertised over BGP sessions is limited to nodes, in a secure manner, inside this trusted SR domain 😭 BGP peering sessions for address families other than the ones using the SR Policy SAFI may be set up to routers outside the SR domain 🦋 Isolating BGP SR Policy SAFI peering sessions can be used to make sure SR Policy information isn't advertised by accident or in error to an EBGP peering session outside the SR domain 🎀

Also, this one is giving "don't let the wrong people see your stuff" energy 🙈 Exporting SR Policy information, as described here, may be a risk to the confidentiality of mission-critical or commercially sensitive information about the network. Specifically, that's endpoint/node addresses, SR SIDs, and the SR Policies deployed 💀

BGP peerings are not automatic and need configuration. So it's the network operator's responsibility to make sure only trusted nodes (routers AND controller applications) inside the SR domain are configured to receive this information 🫶💖

8. Manageability Considerations 🧚

this section is pretty chill, bestie 🌸 The specification of BGP models is ongoing work based on [BGP-YANG-MODEL], and its future extensions are expected to cover the SR Policy SAFI 🍓 Existing BGP operational procedures also apply to the SAFI specified in this document ✨ Managing, operating, and monitoring BGP speakers and the SR Policy SAFI sessions between them isn't very different from other BGP sessions, and they can be managed using the same data models 💅

The YANG data model for operating and managing SR Policies, [SR-POLICY-YANG], reports the SR Policies provisioned via the BGP SR Policy SAFI along with their operational states 👑

9. References 💜

9.1. Normative References 📚

Okay, these are the must-read ones bestie, the references this doc literally can't work without 🫶

[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, https://www.rfc-editor.org/info/rfc1997.
[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.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, https://www.rfc-editor.org/info/rfc2545.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, https://www.rfc-editor.org/info/rfc3032.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, https://www.rfc-editor.org/info/rfc4271.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, February 2006, https://www.rfc-editor.org/info/rfc4360.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, https://www.rfc-editor.org/info/rfc4760.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 2009, https://www.rfc-editor.org/info/rfc5462.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286, June 2011, https://www.rfc-editor.org/info/rfc6286.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, https://www.rfc-editor.org/info/rfc7606.
[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.
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, https://www.rfc-editor.org/info/rfc8660.
[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.
[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.
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, "The BGP Tunnel Encapsulation Attribute", RFC 9012, DOI 10.17487/RFC9012, April 2021, https://www.rfc-editor.org/info/rfc9012.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov, A., and P. Mattes, "Segment Routing Policy Architecture", RFC 9256, DOI 10.17487/RFC9256, July 2022, https://www.rfc-editor.org/info/rfc9256.

9.2. Informative References 💡

These ones are just good to know, not required reading, but they're seriously worth a look 🦋

[BGP-LS-SR-POLICY] Previdi, S., Talaulikar, K., Ed., Dong, J., Gredler, H., and J. Tantsura, "Advertisement of Segment Routing Policies using BGP Link-State", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-ls-sr-policy-17, 6 March 2025, https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-sr-policy-17.
[BGP-YANG-MODEL] Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG Model for Border Gateway Protocol (BGP-4)", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-model-18, 21 October 2024, https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-18.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, https://www.rfc-editor.org/info/rfc4272.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, https://www.rfc-editor.org/info/rfc4456.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, https://www.rfc-editor.org/info/rfc6952.
[RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, https://www.rfc-editor.org/info/rfc9552.
[RFC9831] Talaulikar, K., Ed., Filsfils, C., Previdi, S., Mattes, P., and D. Jain, "Segment Type Extensions for BGP Segment Routing (SR) Policy", RFC 9831, DOI 10.17487/RFC9831, September 2025, https://www.rfc-editor.org/info/rfc9831.
[SR-POLICY-YANG] Raza, K., Ed., Saleh, T., Shunwan, Z., Voyer, D., Durrani, M., Matsushima, S., and V. Beeram, "YANG Data Model for Segment Routing Policy", Work in Progress, Internet-Draft, draft-ietf-spring-sr-policy-yang-05, 25 May 2025, https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-policy-yang-05.

Acknowledgments 🫶

The authors wanted to give a massive shoutout to Shyam Sethuram, John Scudder, Przemyslaw Krol, Alex id Bogdanov, Nandan Saha, Bruno Decraene, Gurusiddesh Nidasesi, Kausik Majumdar, Zafar Ali, Swadesh Agarwal, Jakob Heitz, Viral Patel, Peng Shaofu, Cheng Li, Martin Vigoureux, John Scudder, Vincent Roca, Brian Haberman, Mohamed Boucadair, Shunwan Zhuang, Andrew Alston, Jeffrey (Zhaohui) Zhang, Nagendra Nainar, Rajesh Melarcode Venkateswaran, Nat Kao, Boris Hassanov, Vincent Roca, Russ Housley, and Dan Romascanu for their comments and review of this document. The authors also want to thank Susan Hares for her detailed shepherd review, which made the document so much better ✨

Contributors 💜

These are the people who contributed to the document:

Eric Rosen
Juniper Networks
United States of America
Email: erosen@juniper.net


Arjun Sreekantiah
Cisco Systems
United States of America
Email: asreekan@cisco.com


Acee Lindem
Cisco Systems
United States of America
Email: acee@cisco.com


Siva Sivabalan
Cisco Systems
United States of America
Email: msiva@cisco.com


Imtiyaz Mohammad
Arista Networks
India
Email: imtiyaz@arista.com


Gaurav Dawra
Cisco Systems
United States of America
Email: gdawra.ietf@gmail.com


Peng Shaofu
ZTE Corporation
China
Email: peng.shaofu@zte.com.cn


Steven Lin
Calix
United States of America
Email: steven.lin@calix.com

Authors' Addresses 🎀

And finally, the authors themselves 👑

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


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


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


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

📦 where this page comes from

ietf: rfc9830 2025-09
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms