RFC 8669

Segment Routing Prefix Segment Identifier Extensions for BGP

📅 published December 2019, from ietf

Segment Routing Prefix Segment Identifier Extensions for BGP 🦋

  • RFC number: 8669
  • Category: Standards Track, so this is an official Internet Standards Track document 🔥
  • Date: December 2019
  • ISSN: 2070-1721
  • Authors: S. Previdi (Huawei Technologies), C. Filsfils and A. Lindem, Ed. (Cisco Systems), A. Sreekantiah (the title block doesn't print an affiliation next to his name, so I'm not guessing 🙈), and H. Gredler (RtBrick Inc.)
  • Obsoletes: nothing is listed in the title block 💅
  • Updates: nothing is listed in the title block ✨

Abstract ✨

Segment Routing (SR) is built on the source-routing paradigm 🧚. A node steers a packet through an ordered list of instructions called "segments". A segment can be any instruction, either topological or service based. The ingress node attaches an SR header to the packet, and that header holds a set of segment identifiers (SIDs). Each SID stands for a topological or service-based instruction. Per-flow state lives only on the ingress node of the SR domain 👑. An "SR domain" is a single administrative domain for global SID assignment.

This document defines an optional, transitive BGP attribute for announcing information about BGP Prefix Segment Identifiers (BGP Prefix-SIDs), plus the specification for SR-MPLS SIDs 🎀.

Status of This Memo 📝

This is an Internet Standards Track document 🔥.

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

Info about this document's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8669 🔗.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document 🙏. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

Table of Contents 🗂️

1.  Introduction
2.  MPLS BGP Prefix-SID
3.  BGP Prefix-SID Attribute
  3.1.  Label-Index TLV
  3.2.  Originator SRGB TLV
4.  Receiving BGP Prefix-SID Attribute
  4.1.  MPLS Data Plane: Labeled Unicast
5.  Advertising BGP Prefix-SID Attribute
  5.1.  MPLS Data Plane: Labeled Unicast
6.  Error Handling of BGP Prefix-SID Attribute
7.  IANA Considerations
8.  Manageability Considerations
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 💅

Segment Routing (SR) runs on the source-routing paradigm 🧠. A segment is either a topological instruction, like "go to prefix P following shortest path", or a service instruction. More types of segments might get defined later 🔮.

Every segment is identified by a Segment Identifier (SID). An "SR domain" is a single administrative domain for global SID assignment. It can be one Autonomous System (AS) or several ASes under consolidated global SID administration 🌈. Normally, the ingress node of the SR domain prepends an SR header with SIDs to an incoming packet.

As described in [RFC8402], when SR is applied to the MPLS data plane ([RFC8660]), the SID is a label 🏷️.

[RFC8402] also explains how Segment Routing can run on an IPv6 data plane (SRv6), using an IPv6 routing header that holds a stack of SR SIDs encoded as IPv6 addresses [IPv6-SRH]. Support and applicability for Segment Routing over IPv6 are out of scope for this document 🙅‍♀️.

A BGP Prefix Segment is a BGP prefix with a Prefix-SID attached 🦋. A BGP Prefix-SID is always a global SID ([RFC8402]) within the SR domain, and it names an instruction to forward the packet over the Equal-Cost Multipath (ECMP) best path that BGP computed for the related prefix. The BGP Prefix-SID is the identifier of the BGP Prefix Segment. This document always refers to the BGP Prefix Segment by its BGP Prefix-SID 💖.

This document covers the BGP extensions used to signal the BGP Prefix-SID. Specifically, it defines a BGP attribute called the "BGP Prefix-SID attribute", and it lays out the rules for originating, receiving, and handling error conditions for that attribute ✨.

The BGP Prefix-SID attribute can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC4760] [RFC8277]). Using the attribute with other Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations isn't defined here, but future specs might cover it 🔮.

[RFC8670] walks through example use cases where the BGP Prefix-SID is used with the AFI/SAFI combinations above 📚.

A few things to note 👀:

  • A BGP Prefix-SID will be global across ASes when the interconnected ASes are part of the same SR domain. Otherwise, when ASes are interconnected, the ASBRs of each domain have to handle advertising unique SIDs. The mechanisms for that interconnection are outside the scope of the protocol extensions in this document 🌉.
  • A BGP Prefix-SID MAY be attached to a BGP prefix. That means each prefix gets advertised individually, which cuts down on the ability to pack BGP advertisements that share common attributes 📦.

Heads up, these are the BCP 14 key words. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they appear in all capitals, exactly as shown here 🙏.

2. MPLS BGP Prefix-SID 🌸

The BGP Prefix-SID runs on the MPLS data plane ([RFC8660]) like this:

The operator assigns a globally unique label index, L_I, to a locally originated prefix of a BGP speaker N. That prefix is advertised to all other BGP speakers in the SR domain 🏷️.

According to [RFC8402], every BGP speaker is configured with a label block called the Segment Routing Global Block (SRGB) 🧱. [RFC8402] recommends using the same SRGB across all nodes in the SR domain. Still, the SRGB of a node is a local property and can differ between speakers. The drawbacks of having BGP speakers with different SRGBs are documented in [RFC8402] and [RFC8670] ⚠️.

If traffic engineering within the SR domain is needed, each node may also have to advertise topological information and Peer SIDs for each of its links and peers 🛣️. That information is required to do explicit path computation and to express an explicit path as a list of SIDs. The topological information and peer segments (Peer SIDs) are advertised through [BGPLS-SR-EPE].

If a prefix segment goes into an MPLS label stack, for example for traffic-engineering purposes, you need to know the prefix originator's SRGB so you can compute the local label the originator uses 🧮.

This document assumes Border Gateway Protocol - Link State (BGP-LS) is the preferred way to collect both peer segments (Peer SIDs) and SRGB information, through [RFC7752], [BGPLS-SR-EPE], and [BGPLS-SR-EXT]. As an optional alternative for advertising the local SRGB without topology or Peer SIDs, the Originator SRGB TLV of the BGP Prefix-SID attribute is specified in Section 3.2 of this document. That route has no applicability for TE, though 🙃.

A BGP speaker derives its local MPLS label L from the label index L_I and its local SRGB, as described in [RFC8660]. Then it programs the MPLS label L into its MPLS data plane as its incoming/local label for the prefix. See Section 4.1 for more details 🔍.

The outgoing label for the prefix is found in the Network Layer Reachability Information (NLRI) of the Multiprotocol BGP IPv4/IPv6 Labeled Unicast prefix advertisement, as defined in [RFC8277]. The label index L_I is only a hint used to derive the local/incoming label 💡.

Section 3.1 of this document specifies the Label-Index TLV of the BGP Prefix-SID attribute. This TLV can be used to advertise the label index for a given prefix 🎁.

3. BGP Prefix-SID Attribute 👑

The BGP Prefix-SID attribute is an optional, transitive BGP path attribute. IANA assigned attribute type code 40 (see Section 7) 🔢.

The attribute is a set of elements encoded as "Type/Length/Value" tuples, meaning a set of TLVs 🧩. Every BGP Prefix-SID attribute TLV starts with a 1-octet type and a 2-octet length. This document defines the following TLVs:

  • Label-Index TLV
  • Originator SRGB TLV

The Label-Index and Originator SRGB TLVs are only used when SR is applied to the MPLS data plane 🌈.

For future extensibility, unknown TLVs MUST be ignored and propagated unmodified 🫶.

3.1. Label-Index TLV 🧚

The Label-Index TLV MUST be present in the BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). It MUST be ignored when received for other BGP AFI/SAFI combinations. 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    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Flags              |       Label Index             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Label Index          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each field means 🔍:

  • Type: 1.
  • Length: 7, which is the total length in octets of the value portion of the TLV.
  • RESERVED: An 8-bit field. It MUST be clear on transmission and MUST be ignored on reception 🚫.
  • Flags: 16 bits of flags. None are defined by this document. The Flags field MUST be clear on transmission and MUST be ignored on reception 🚫.
  • Label Index: A 32-bit value representing the index value in the SRGB space 🔢.

3.2. Originator SRGB TLV ✨

okay so the Originator SRGB TLV is totally optional 🎀 but it's giving real main character energy when it shows up. 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      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Flags     |
 +-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         SRGB 1 (6 octets)                                     |
 |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |         SRGB n (6 octets)                                     |
 |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here's what each piece means 💅:

  • Type: 3
  • Length: the total length in octets of the value portion of the TLV, which is 2 + (non-zero multiple of 6). bestie, that math is the whole vibe 🧮
  • Flags: 16 bits of flags, and none are defined in this document 🍓 The Flags field MUST be clear on transmission and MUST be ignored on reception.
  • SRGB: 3 octets for the first label in the range, followed by 3 octets for the number of labels in the range. The SRGB field MAY appear multiple times, and if it does, the SRGB is made of multiple ranges that get concatenated 🌈

The Originator SRGB TLV carries the SRGB of the node that originated the prefix the BGP Prefix-SID is attached to. 🦋 It MUST NOT be changed during the propagation of the BGP update. It's used to build SR policies when different SRGBs show up in the fabric, for example, [RFC8670].

Examples of how receiving routers concatenate the ranges and build their neighbor's Segment Routing Global Block (SRGB) are included in [RFC8660] 📚

The Originator SRGB TLV may only appear in a BGP Prefix-SID attribute attached to IPv4/IPv6 Labeled Unicast prefixes ([RFC8277]). If it shows up on any other BGP AFI/SAFI combination, it MUST be ignored 🙈 Since the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the Originator SRGB TLV will be ignored if it isn't specified in a manner consistent with Section 6.

Now for the drama 🍿 If a BGP speaker gets a node's SRGB as an attribute of the BGP-LS Node NLRI, AND it also gets that same node's SRGB inside a BGP Prefix-SID attribute, then the received values should be the same. If they're different, the values advertised in the BGP-LS NLRI SHOULD be preferred, and an error should be logged 😭

4. Receiving BGP Prefix-SID Attribute 🫶

A BGP speaker that receives a BGP Prefix-SID attribute from an External BGP (EBGP) neighbor residing outside the boundaries of the SR domain MUST discard the attribute, unless it's configured to accept the attribute from that EBGP neighbor. 🚫 A BGP speaker SHOULD log an error for further analysis when it discards an attribute.

4.1. MPLS Data Plane: Labeled Unicast 🧚

A BGP session supporting the Multiprotocol BGP Labeled IPv4 or IPv6 Unicast ([RFC8277]) AFI/SAFI is required.

When the BGP Prefix-SID attribute is attached to a BGP Labeled IPv4 or IPv6 Unicast [RFC8277] AFI/SAFI, it MUST contain the Label-Index TLV and MAY contain the Originator SRGB TLV. A BGP Prefix-SID attribute received without a Label-Index TLV MUST be considered to be "invalid" by the receiving speaker 💀

The label index gives the receiving BGP speaker guidance on the incoming label that SHOULD be allocated to the prefix 🎯

A BGP speaker may be locally configured with SRGB=[SRGB_Start, SRGB_End]. Which method it uses to derive the SRGB is a matter of local node configuration ⚙️

The mechanisms through which a given label-index value gets assigned to a given prefix are outside the scope of this document. Not our tea here 🍵

Given a label index L_I, we refer to L = L_I + SRGB_Start as the derived label. A BGP Prefix-SID attribute is designated "conflicting" for a speaker M if the derived label value L lies outside the SRGB configured on M. Otherwise, the Label-Index TLV is designated "acceptable" to speaker M. ✅❌

If multiple different prefixes are received with the same label index, then all of the different prefixes MUST have their BGP Prefix-SID attribute considered to be "conflicting". Two prefixes, one index, zero friends 💔

If multiple valid paths for the same prefix are received from multiple BGP speakers, or, in the case of [RFC7911], from the same BGP speaker, and the BGP Prefix-SID attributes do NOT contain the same label index, then the label index from the best path BGP Prefix-SID attribute SHOULD be chosen. There's a notable exception when [RFC5004] is being used to dampen route changes 🌊

When a BGP speaker receives a path from a neighbor with an "acceptable" BGP Prefix-SID attribute and that path is selected as the best path, it SHOULD program the derived label as the label for the prefix in its local MPLS data plane. 🔥

When a BGP speaker receives a path from a neighbor with an "invalid" or "conflicting" BGP Prefix-SID attribute, or when it receives a path from a neighbor with a BGP Prefix-SID attribute but is unable to process it (e.g., local policy disables the functionality), it MUST ignore the BGP Prefix-SID attribute. For label allocation purposes, a BGP speaker MUST assign a local (also called dynamic) label (non-SRGB) for such a prefix, as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. 🧃

For an "invalid" BGP Prefix-SID attribute, a BGP speaker MUST follow the error-handling rules specified in Section 6. A BGP speaker SHOULD log an error for further analysis. For a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT treat it as an error, and SHOULD propagate the attribute unchanged. A BGP speaker SHOULD log a warning for further analysis, i.e., in the case the conflict is not due to a label-index transition. 📝

When a BGP Prefix-SID attribute changes and transitions from "conflicting" to "acceptable", the BGP Prefix-SID attributes for other prefixes may also transition to "acceptable" as well. Implementations SHOULD ensure all impacted prefixes revert to using the label indices corresponding to these newly "acceptable" BGP Prefix-SID attributes. It's like a glow-up domino effect 🌸

The outgoing label is always programmed as per classic Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]) operation. Specifically, a BGP speaker that receives a prefix with a BGP Prefix-SID attribute, and a label NLRI field of Implicit NULL [RFC3032] from a neighbor, MUST adhere to standard behavior and program its MPLS data plane to pop the top label when forwarding traffic to the prefix. The label NLRI defines the outbound label that MUST be used by the receiving node. 🚀

5. Advertising BGP Prefix-SID Attribute 📣

The BGP Prefix-SID attribute MAY be attached to BGP IPv4/IPv6 Labeled Unicast prefixes [RFC8277]. To stop the BGP Prefix-SID attribute from spreading beyond its intended scope of applicability, attribute filtering SHOULD be deployed to remove it at the administrative boundary of the SR domain 🚧

A BGP speaker that advertises a path received from one of its neighbors SHOULD advertise the BGP Prefix-SID received with the path without modification, as long as the BGP Prefix-SID was acceptable 🎀 If the path did not come with a BGP Prefix-SID attribute, the speaker MAY attach a BGP Prefix-SID to the path if it's configured to do so. The content of the TLVs present in the BGP Prefix-SID is determined by configuration 🧁

5.1. MPLS Data Plane: Labeled Unicast 🌈

A BGP speaker that originates a prefix attaches the BGP Prefix-SID attribute when it advertises the prefix to its neighbors via Multiprotocol BGP IPv4/IPv6 Labeled Unicast ([RFC8277]). The value of the label index in the Label-Index TLV is determined by configuration.

A BGP speaker that originates a BGP Prefix-SID attribute MAY optionally announce the Originator SRGB TLV along with the mandatory Label-Index TLV. The content of the Originator SRGB TLV is determined by configuration.

Since the label-index value must be unique within an SR domain, by default an implementation SHOULD NOT advertise the BGP Prefix-SID attribute outside an AS, unless it is explicitly configured to do so 🛑

In all cases, the Label field of the advertised NLRI ([RFC8277] [RFC4364]) MUST be set to the local/incoming label programmed in the MPLS data plane for the given advertised prefix. If the prefix is associated with one of the BGP speaker's interfaces, this is the usual MPLS label, such as the Implicit or Explicit NULL label [RFC3032]. 🫧

6. Error Handling of BGP Prefix-SID Attribute 🚨

When a BGP speaker receives a BGP UPDATE message containing a malformed or invalid BGP Prefix-SID attribute attached to an IPv4/IPv6 Labeled Unicast prefix ([RFC8277]), it MUST ignore the received BGP Prefix-SID attribute and MUST NOT advertise it to other BGP peers. 🙅‍♀️

In this context, a malformed BGP Prefix-SID attribute is one that can't be parsed, for any of these reasons: it doesn't meet the minimum attribute length requirement, it contains a TLV length that doesn't conform to the length constraints for that TLV, or it contains a TLV length that would extend beyond the end of the attribute (as defined by the attribute length). 🧩 This is equivalent to the "Attribute discard" action specified in [RFC7606]. When discarding an attribute, a BGP speaker SHOULD log an error for further analysis.

As per [RFC7606], if the BGP Prefix-SID attribute appears more than once in an UPDATE message, all the occurrences of the attribute other than the first one SHALL be discarded, and the UPDATE message will continue to be processed 🔁 Similarly, if a recognized TLV appears more than once in a BGP Prefix-SID attribute while the specification only allows for a single occurrence, then all the occurrences of the TLV other than the first one SHALL be discarded, and the Prefix-SID attribute will continue to be processed. Only the first one gets to stay, iykyk 👑

For future extensibility, unknown TLVs MUST be ignored and propagated unmodified. 🦋

7. IANA Considerations 🎀

okay so this doc defines a BGP path attribute called the BGP Prefix-SID attribute 💅 and IANA gave it attribute code type 40 from the "BGP Path Attributes" registry 🌸

it also defines two TLVs for the BGP Prefix-SID attribute, and both are officially registered with IANA ✨ IANA made a brand new registry for them, so under the "Border Gateway Protocol (BGP) Parameters" registry you'll find "BGP Prefix-SID TLV Types" pointing right back to this document 🦋

the registration procedure is giving organized 🗂️

   Values 1-254, Expert Review as defined in [RFC8126]
   Values 0 and 255, Reserved

and the actual table of values is literally this:

   +-------+-----------------+---------------+
   | Value | Type            | Reference     |
   +=======+=================+===============+
   | 0     | Reserved        | This document |
   +-------+-----------------+---------------+
   | 1     | Label-Index     | This document |
   +-------+-----------------+---------------+
   | 2     | Deprecated      | This document |
   +-------+-----------------+---------------+
   | 3     | Originator SRGB | This document |
   +-------+-----------------+---------------+
   | 4-254 | Unassigned      |               |
   +-------+-----------------+---------------+
   | 255   | Reserved        | This document |
   +-------+-----------------+---------------+

Table 1: BGP Prefix-SID TLV Types 📋

so value 2 used to be the IPv6 SID TLV, which was in earlier versions of this doc 🥹 it got removed, and using the BGP Prefix-SID for Segment Routing over the IPv6 data plane [RFC8402] has been pushed off to future specs. that's the tea ☕

two more registries got made too, both under "Border Gateway Protocol (BGP) Parameters" and both pointing to this doc 🌈 first up is "BGP Prefix-SID Label-Index TLV Flags", a 16-bit flags registry that starts out totally empty 🫙 the registration policy for flag bits is Expert Review [RFC8126], which matches the "BGP Prefix-SID TLV Types" registry.

last one is "BGP Prefix-SID Originator SRGB TLV Flags", also a 16-bit flags registry that starts empty, and it uses Expert Review [RFC8126] too, consistent with the BGP Prefix-SID TLV Types registry 🍓

the designated experts must be good and faithful stewards of all of these registries 🧚 they make sure every request is legit and matches a viable use case. flag bits are kinda scarce (only 16 per registry!) and each flag only applies to one TLV, so additional scrutiny should be afforded to flag-bit requests. in general, no single use case should need more than one flag bit, and if a use case needs more, alternate encodings using new TLVs should be considered 💜

8. Manageability Considerations 🦋

this doc defines a BGP attribute to handle use cases like the one in [RFC8670] 🌸 it's assumed that the operator controls whether the BGP Prefix-SID attribute gets advertised, so they can:

  • Prevent undesired origination/advertisement of the BGP Prefix-SID attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be attached to a prefix and advertised. Hence, BGP Prefix-SID Advertisement SHOULD require explicit enablement. 🔒
  • Prevent any undesired propagation of the BGP Prefix-SID attribute. By default, the BGP Prefix-SID is not advertised outside the boundary of a single SR/administrative domain that may include one or more ASes. The propagation to other ASes MUST be explicitly configured. 🚧

the deployment model in [RFC8670] assumes multiple ASes under one common administrative domain 👑 for that use case, BGP Prefix-SID Advertisement applies to the inter-AS context, meaning EBGP, while staying confined to a single administrative domain. main character energy, but make it organized 💅

9. Security Considerations 💀

okay security is serious bestie 😭 this doc introduces a BGP attribute (BGP Prefix-SID), and it inherits the security considerations from [RFC4271], [RFC8277], and [RFC8402]. read those, no skipping 🙈

when it's advertised using BGPsec as described in [RFC8205], the BGP Prefix-SID attribute doesn't add any unique security considerations. however, it should be noted that the BGP Prefix-SID attribute is not protected by the BGPsec signatures 🚨

also, as described in Section 8, this doc is about a deployment model where all nodes are under a single administrative domain. in that setup, we assume the operator doesn't want to leak any info about internal prefixes and topology outside the administrative domain 🫣 the internal info includes the BGP Prefix-SID. to stop that leaking, the common BGP mechanisms (filters) get applied at the boundary of the SR/administrative domain. local BGP-attribute-filtering policies and mechanisms are not standardized, so they're beyond this doc's scope 🧱

to prevent a Denial-of-Service (DoS) or Distributed-Denial-of-Service (DDoS) attack caused by excessive BGP updates with an invalid or conflicting BGP Prefix-SID attribute, error log message rate limiting as well as suppression of duplicate error log messages SHOULD be deployed 🛡️

and since BGP-LS is the preferred method for advertising SRGB information, the BGP speaker SHOULD log an error if a BGP Prefix-SID attribute is received with SRGB information different from what it got as an attribute of the same node's BGP-LS Node NLRI 🔍 it's giving detective era, and I'm obsessed ✨

10. References 📚

10.1. Normative References

10.2. Informative References

Acknowledgements 🎀

Okay bestie, the authors wanna give a shoutout to everyone who helped make this doc happen 🫶

The authors would like to thank Satya Mohanty for his contribution to this document 💖

The authors would like to thank Alvaro Retana for substantive comments as part of the Routing AD review ✨

The authors would like to thank Bruno Decraene for substantive comments and suggested text as part of the Routing Directorate review 🔥

The authors would like to thank Shyam Sethuram for comments and discussion of TLV processing and validation 💅

The authors would like to thank Robert Raszuk for comments and suggestions regarding the MPLS data-plane behavior 🦋

The authors would like to thank Krishna Deevi, Juan Alcaide, Howard Yang, and Jakob Heitz for discussions on conflicting BGP Prefix-SID label indices and BGP add paths 🌈

The authors would like to thank Peter Yee, Tony Przygienda, Mirja Kuhlewind, Alexey Melnikov, Eric Rescorla, Suresh Krishnan, Warren Kumari, Ben Campbell Sue Hares, and Martin Vigoureux for IDR Working Group last call, IETF Last Call, directorate, and IESG reviews 👑😭

Contributors 🌸

Meet the contributors, the people who put in the extra work 🧚

Keyur Patel
Arrcus, Inc.
United States of America

Email: Keyur@arrcus.com

Saikat Ray
Unaffiliated
United States of America

Email: raysaikat@gmail.com

Authors' Addresses 💌

And here are the authors, with their contact details so you can slide into their DMs about BGP Prefix-SID stuff 🍓

Stefano Previdi
Huawei Technologies
Italy

Email: stefano@previdi.net


Clarence Filsfils
Cisco Systems
Brussels
Belgium

Email: cfilsfil@cisco.com


Acee Lindem (editor)
Cisco Systems
301 Midenhall Way
Cary, NC,  27513
United States of America

Email: acee@cisco.com


Arjun Sreekantiah

Email: arjunhrs@gmail.com


Hannes Gredler
RtBrick Inc.

Email: hannes@rtbrick.com
📦 where this page comes from