RFC 9086

Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering

📅 published August 2021, from ietf

RFC 9086 🦋 Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering

Okay bestie, let's get into it 💖 This one is an IETF Standards Track document (ISSN 2070-1721) dated August 2021. The authors are S. Previdi (Huawei Technologies), K. Talaulikar, Ed. and C. Filsfils (Cisco Systems, Inc.), K. Patel (Arrcus, Inc.), S. Ray (Individual), and J. Dong (Huawei Technologies). The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Abstract 🌸

So a node steers a packet through a controlled set of instructions, called segments, by stacking a list of segment identifiers (SIDs) on the packet. A segment can be any instruction, topological or service based. SR segments let you steer a flow through any topological path and service chain while keeping per-flow state only at the ingress node of the SR domain. Iconic 🔥

This document describes an extension to Border Gateway Protocol - Link State (BGP-LS). It advertises BGP Peering Segments along with their BGP peering node information, so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing ✨

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9086.

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🧚

   1.  Introduction
   2.  Requirements Language
   3.  BGP Peering Segments
   4.  BGP-LS NLRI Advertisement for BGP Protocol
     4.1.  BGP Router-ID and Member AS Number
     4.2.  Mandatory BGP Node Descriptors
     4.3.  Optional BGP Node Descriptors
   5.  BGP-LS Attributes for BGP Peering Segments
     5.1.  Advertisement of the PeerNode SID
     5.2.  Advertisement of the PeerAdj SID
     5.3.  Advertisement of the PeerSet SID
   6.  IANA Considerations
     6.1.  New BGP-LS Protocol-ID
     6.2.  Node Descriptors and Link Attribute TLVs
   7.  Manageability Considerations
   8.  Security Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Contributors
   Authors' Addresses

1. Introduction ✨

Segment Routing (SR) is basically source routing, and it's giving main character 🦋 A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with a list of segment identifiers (SIDs). A SID can represent any instruction, topological or service based. SR segments let you enforce a flow through any topological path or service function, while keeping per-flow state only at the ingress node of the SR domain.

The SR architecture [RFC8402] defines three types of BGP Peering Segments that may be instantiated at a BGP node:

  • Peer Node Segment (PeerNode SID): instruction to steer to a specific peer node
  • Peer Adjacency Segment (PeerAdj SID): instruction to steer over a specific local interface towards a specific peer node
  • Peer Set Segment (PeerSet SID): instruction to load-balance to a set of specific peer nodes

SR can go straight onto an MPLS data plane (SR-MPLS) with no change on the forwarding plane, or onto a modified IPv6 forwarding plane (SRv6). 💅

This document describes extensions to the BGP - Link State Network Layer Reachability Information (BGP-LS NLRI) and the BGP-LS Attribute defined for BGP-LS [RFC7752]. These let a BGP node advertise its BGP peering segments along with its peering topology information (that is, its peers, interfaces, and peering Autonomous Systems (ASes)). The goal is to enable computation of efficient BGP Egress Peer Engineering (BGP-EPE) policies and strategies using the SR-MPLS data plane. The corresponding extensions for SRv6 are specified in [BGPLS-SRV6].

[RFC9087] illustrates a centralized controller-based BGP Egress Peer Engineering solution involving SR path computation using the BGP Peering Segments. In this use case, a centralized controller learns the BGP Peering SIDs via BGP-LS, then uses that information to program a BGP-EPE policy at any node in the domain. That policy steers traffic via a specific BGP egress node to specific External BGP (EBGP) peer(s), optionally also over a specific interface. The BGP-EPE policy can be realized using the SR Policy framework [SR-POLICY].

This document introduces a new BGP-LS Protocol-ID for BGP and defines new BGP-LS Node and Link Descriptor TLVs. These facilitate advertising BGP-LS Link NLRI to represent the BGP peering topology. It also specifies the BGP-LS Attribute TLVs for advertising the BGP Peering Segments (that is, PeerNode SID, PeerAdj SID, and PeerSet SID), which are advertised in the same BGP-LS Link NLRI. 🎀

2. Requirements Language 🎀

Okay so the capital-letter words get special powers, and here's the official rule 🙈

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

3. BGP Peering Segments 🦋

As described in [RFC8402], a BGP-EPE-enabled Egress Provider Edge (PE) node instantiates SR Segments corresponding to its attached peers. These segments are called BGP Peering Segments or BGP Peering SIDs. In the case of EBGP, they enable the expression of source-routed interdomain paths.

Picture this: an ingress border router of an AS wants a flow to take a selected path within the AS, out through a selected egress border router of the AS, and on to a specific EBGP peer. It composes a list of SIDs to make that happen. At minimum, a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node SID of the chosen egress PE, and then the BGP Peering SID for the chosen egress PE peer or peering interface.

Each BGP session MUST be described by a PeerNode SID. The description of the BGP session MAY be augmented by additional PeerAdj SIDs. Finally, multiple PeerNode SIDs or PeerAdj SIDs MAY be part of the same group/set, so that EPE resources are grouped under a common PeerSet SID. These BGP Peering SIDs and their encoding are described in detail in Section 5.

The following BGP Peering SIDs need to be instantiated on a BGP router for each of its BGP peer sessions that are enabled for Egress Peer Engineering:

  • One PeerNode SID MUST be instantiated to describe the BGP peer session.
  • One or more PeerAdj SID MAY be instantiated, corresponding to the underlying link(s) to the directly connected BGP peer session.
  • A PeerSet SID MAY be instantiated, and additionally associated and shared between one or more PeerNode SIDs or PeerAdj SIDs.

Now here's the tea 🍓 While an egress point in a topology usually refers to EBGP sessions between external peers, nothing in the extensions defined in this document would prevent using them in the context of Internal BGP (IBGP) sessions. However, unlike EBGP sessions, which are generally between directly connected BGP routers also along the traffic forwarding path, IBGP peer sessions may be set up to BGP routers that are not in the forwarding path. So when the IBGP design includes sessions with route reflectors, a BGP router SHOULD NOT instantiate a BGP Peering SID for those sessions to peer nodes that are not in the forwarding path. The whole point of a BGP Peering SID is to steer traffic to those specific peers. The applicability for IBGP peering may therefore be limited to only those deployments where the IBGP peer is also along the forwarding data path. 👑

Any BGP Peering SIDs instantiated on the node are advertised via the BGP-LS Link NLRI type, as described in the sections below. An illustration of the BGP Peering SIDs' allocations in a reference BGP peering topology, along with the information carried in the BGP-LS Link NLRI and its corresponding BGP-LS Attribute, is given in [RFC9087].

4. BGP-LS NLRI Advertisement for BGP Protocol 💜

This section is all about the BGP-LS NLRI encodings that describe the BGP peering and link connectivity between BGP routers.

This document specifies the advertisement of BGP peering topology information via the BGP-LS Link NLRI type, which requires use of a new BGP-LS Protocol-ID.

            +=============+==================================+
            | Protocol-ID | NLRI Information Source Protocol |
            +=============+==================================+
            |      7      | BGP                              |
            +-------------+----------------------------------+

               Table 1: BGP-LS Protocol Identifier for BGP

The new Protocol-ID lets you tell apart the BGP-LS NLRIs carrying BGP information from the BGP-LS NLRIs carrying IGP link-state information defined in [RFC7752] 🌈

The BGP Peering information, along with the Peering Segments, is advertised using the BGP-LS Link NLRI type with the Protocol-ID set to BGP. The BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS Attribute TLVs defined in [RFC7752]. To correctly describe BGP nodes, new TLVs are defined in this section.

[RFC7752] defines the BGP-LS Link NLRI type 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
   +-+-+-+-+-+-+-+-+
   |  Protocol-ID  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Identifier                          |
   |                            (64 bits)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //      Local Node Descriptors                                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //      Remote Node Descriptors                                //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //      Link Descriptors                                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 1: BGP-LS Link NLRI

Node Descriptors and Link Descriptors are defined in [RFC7752].

4.1. BGP Router-ID and Member AS Number 🎀

okay bestie, this section adds two brand new Node Descriptor TLVs 💅 Here they are:

  • BGP Router Identifier (BGP Router-ID) 🌸
    • Type: 516
    • Length: 4 octets
    • Value: 4-octet unsigned non-zero integer representing the BGP Identifier as defined in [RFC6286]
  • Member-AS Number (Member-ASN) 🦋
    • Type: 517
    • Length: 4 octets
    • Value: 4-octet unsigned non-zero integer representing the Member-AS Number [RFC5065]

4.2. Mandatory BGP Node Descriptors 👑

the following Node Descriptor TLVs MUST be included in BGP-LS NLRI as Local Node Descriptors when you're distributing BGP info, no skipping 😤

  • BGP Router-ID (TLV 516), which contains a valid BGP Identifier of the local BGP node. 💖
  • Autonomous System Number (TLV 512) [RFC7752], which contains the Autonomous System Number (ASN) or AS Confederation Identifier (an ASN) [RFC5065], if confederations are used, of the local BGP node. 🍓

ngl, Section 2.1 of [RFC6286] is the one that says the BGP identifier (Router-ID) has to be unique within an Autonomous System and non-zero. 🤓 So the <ASN, BGP Router-ID> tuple ends up globally unique, which is iconic. These two together help map Link-State NLRIs with BGP protocol-ID to one specific BGP router in the administrative domain where BGP-LS is enabled 🧚

the following Node Descriptor TLVs MUST be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP info too 🫶

  • BGP Router-ID (TLV 516), which contains the valid BGP Identifier of the peer BGP node. ✨
  • Autonomous System Number (TLV 512) [RFC7752], which contains the ASN or the AS Confederation Identifier (an ASN) [RFC5065], if confederations are used, of the peer BGP node. 🌈

4.3. Optional BGP Node Descriptors 🌟

these are the optional ones, so no pressure 😌 The following Node Descriptor TLVs MAY be included in BGP-LS NLRI as Local Node Descriptors when distributing BGP info:

  • Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the local BGP node. 🎀
  • Node Descriptors as defined in [RFC7752]. 💜

The following Node Descriptor TLVs MAY be included in BGP-LS Link NLRI as Remote Node Descriptors when distributing BGP info:

  • Member-ASN (TLV 517), which contains the ASN of the confederation member (i.e., Member-AS Number), if BGP confederations are used, of the peer BGP node. 🦋
  • Node Descriptors as defined in [RFC7752]. 🌸

5. BGP-LS Attributes for BGP Peering Segments 🦋

okay, this section is where the good stuff lives ✨ It defines the BGP-LS Attributes for these three BGP Peer Segment SIDs:

  • Peer Node Segment Identifier (PeerNode SID) 💖
  • Peer Adjacency Segment Identifier (PeerAdj SID) 🫶
  • Peer Set Segment Identifier (PeerSet SID) 👑

the following new BGP-LS Link Attribute TLVs are for BGP-LS Link NLRI, so you can advertise BGP Peering SIDs 💅

                 +================+==============+
                 | TLV Code Point | Description  |
                 +================+==============+
                 | 1101           | PeerNode SID |
                 +----------------+--------------+
                 | 1102           | PeerAdj SID  |
                 +----------------+--------------+
                 | 1103           | PeerSet SID  |
                 +----------------+--------------+

                      Table 2: BGP-LS TLV Code
                         Points for BGP-EPE

PeerNode SID, PeerAdj SID, and PeerSet SID all share the exact same format, which is honestly so clean 🧚

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Type            |              Length           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         |     Weight    |             Reserved          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   SID/Label/Index (variable)                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: BGP Peering SIDs TLV Format

here's the breakdown, bestie 🌈

  • Type: 1101, 1102, or 1103 as listed in Table 2 🎀
  • Length: variable. Valid values are either 7 or 8 depending on whether the encoding is done as a SID Index or a label. 🍓
  • Flags: one octet of flags with the following definition: 🌸
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|L|B|P| Rsvd  |
+-+-+-+-+-+-+-+-+

              Figure 3: Peering SID TLV Flags Format
  • V-Flag: Value Flag. If set, then the SID carries a label value. By default, the flag is SET. 💜
  • L-Flag: Local Flag. If set, then the value/index carried by the SID has local significance. By default, the flag is SET. 🦋
  • B-Flag: Backup Flag. If set, the SID refers to a path that is eligible for protection using fast reroute (FRR). The computation of the backup forwarding path and its association with the BGP Peering SID forwarding entry is implementation specific. Section 3.6 of [RFC9087] discusses some of the possible ways of identifying backup paths for BGP Peering SIDs. 🔥
  • P-Flag: Persistent Flag: If set, the SID is persistently allocated, i.e., the SID value remains consistent across router restart and session/interface flap. 🫶
  • Rsvd bits: Reserved for future use and MUST be zero when originated and ignored when received. 🙈
  • Weight: 1 octet. The value represents the weight of the SID for the purpose of load balancing. An example use of the weight is described in [RFC8402]. ⭐
  • SID/Index/Label. According to the TLV length and the V- and L-Flag settings, it contains either: 🧚
    • A 3-octet local label where the 20 rightmost bits are used for encoding the label value. In this case, the V- and L-Flags MUST be SET. 💖
    • A 4-octet index defining the offset in the Segment Routing Global Block (SRGB) [RFC8402] advertised by this router. In this case, the SRGB MUST be advertised using the extensions defined in [RFC9085]. 👑

the values of the PeerNode SID, PeerAdj SID, and PeerSet SID Sub-TLVs SHOULD be persistent across router restart. 🫶 That's the vibe you want.

when enabled for Egress Peer Engineering, the BGP router MUST include the PeerNode SID TLV in the BGP-LS Attribute for the BGP-LS Link NLRI corresponding to its BGP peering sessions. The PeerAdj SID and PeerSet SID TLVs MAY be included in the BGP-LS Attribute for the BGP-LS Link NLRI. 🌸

Additional BGP-LS Link Attribute TLVs as defined in [RFC7752] MAY be included with the BGP-LS Link NLRI so you can advertise the characteristics of the peering link 💅 For example, one or more interface addresses (TLV 259 or TLV 261) of the underlying link(s) over which a multi-hop BGP peering session is set up may be included in the BGP-LS Attribute along with the PeerNode SID TLV. ✨

5.1. Advertisement of the PeerNode SID 🌟

The PeerNode SID TLV includes a SID associated with the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 4. ✨

The PeerNode SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]):

  • SR operation: NEXT
  • Next-Hop: the connected peering node to which the segment is associated 🦋

The PeerNode SID is advertised with a BGP-LS Link NLRI, where:

  • Local Node Descriptors include:
    • Local BGP Router-ID (TLV 516) of the BGP-EPE-enabled Egress PE 🎀
    • Local ASN (TLV 512) 🍓
  • Remote Node Descriptors include:
    • Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session) 💜
    • Peer ASN (TLV 512) 🌈
  • Link Descriptors include the addresses used by the BGP session encoded using TLVs as defined in [RFC7752]:
    • IPv4 Interface Address (TLV 259) contains the BGP session IPv4 local address. 🌸
    • IPv4 Neighbor Address (TLV 260) contains the BGP session IPv4 peer address. 🫶
    • IPv6 Interface Address (TLV 261) contains the BGP session IPv6 local address. 💖
    • IPv6 Neighbor Address (TLV 262) contains the BGP session IPv6 peer address. 👑
  • Link Attribute TLVs include the PeerNode SID TLV as defined in Figure 2. 🔥

5.2. Advertisement of the PeerAdj SID 🦋

The PeerAdj SID TLV includes a SID associated with the underlying link to the BGP peer node that is described by a BGP-LS Link NLRI as specified in Section 4. 💅

The PeerAdj SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]):

  • SR operation: NEXT
  • Next-Hop: the interface peer address 🧚

The PeerAdj SID is advertised with a BGP-LS Link NLRI, where:

  • Local Node Descriptors include:
    • Local BGP Router-ID (TLV 516) of the BGP-EPE-enabled Egress PE 🎀
    • Local ASN (TLV 512) 🍓
  • Remote Node Descriptors include:
    • Peer BGP Router-ID (TLV 516) (i.e., the peer BGP ID used in the BGP session) 💜
    • Peer ASN (TLV 512) 🌈
  • Link Descriptors MUST include the following TLV, as defined in [RFC7752]:
    • Link Local/Remote Identifiers (TLV 258) contains the 4-octet Link Local Identifier followed by the 4-octet Link Remote Identifier. The value 0 is used by default when the link remote identifier is unknown. ⭐
  • Additional Link Descriptors TLVs, as defined in [RFC7752], MAY also be included to describe the addresses corresponding to the link between the BGP routers:
    • IPv4 Interface Address (Sub-TLV 259) contains the address of the local interface through which the BGP session is established. 🌸
    • IPv6 Interface Address (Sub-TLV 261) contains the address of the local interface through which the BGP session is established. 🫶
    • IPv4 Neighbor Address (Sub-TLV 260) contains the IPv4 address of the peer interface used by the BGP session. 💖
    • IPv6 Neighbor Address (Sub-TLV 262) contains the IPv6 address of the peer interface used by the BGP session. 👑
  • Link Attribute TLVs include the PeerAdj SID TLV as defined in Figure 2. 🔥

5.3. Advertisement of the PeerSet SID 💜

The PeerSet SID TLV includes a SID that is shared amongst BGP peer nodes or the underlying links that are described by BGP-LS Link NLRI as specified in Section 4. 🦋

The PeerSet SID, at the BGP node advertising it, has the following semantics (as defined in [RFC8402]):

  • SR operation: NEXT
  • Next-Hop: load-balance across any connected interface to any peer in the associated peer set 🌈

The PeerSet SID TLV containing the same SID value (encoded as defined in Figure 2) is included in the BGP-LS Attribute for all of the BGP-LS Link NLRI corresponding to the PeerNode or PeerAdj segments associated with the peer set. 🎀 Same SID, every link in the set, very organised ✨

6. IANA Considerations 📋

this document defines the following, and IANA is in charge of the registries 🌸

  • A new Protocol-ID: BGP. The code point is from the "BGP-LS Protocol-IDs" registry. 🍓
  • Two new TLVs: BGP-Router-ID and BGP Confederation Member. The code points are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 💖
  • Three new BGP-LS Attribute TLVs: PeerNode SID, PeerAdj SID, and PeerSet SID. The code points are in the "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry. 👑

6.1. New BGP-LS Protocol-ID 🎀

okay so the IANA folks get their own little section, and this document adds a new value to the registry "BGP-LS Protocol-IDs" ✨ Protocol-ID 7 is now officially BGP, and it points right back to RFC 9086 💖

+=============+==================================+===========+
| Protocol-ID | NLRI information source protocol | Reference |
+=============+==================================+===========+
| 7           | BGP                              | RFC 9086  |
+-------------+----------------------------------+-----------+

                 Table 3: BGP-LS Protocol-ID

this section is giving TLV glow-up 🧚 It adds five brand new TLVs to the registry "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" 🦋 Two are Node Descriptor TLVs and three are Link Attribute TLVs, and all five code points live in that same registry, no cap 👑

  • Two new Node Descriptor TLVs
  • Three new Link Attribute TLVs

The Node Descriptor ones are:

      +================+==========================+===========+
      | TLV Code Point | Description              | Reference |
      +================+==========================+===========+
      | 516            | BGP Router-ID            | RFC 9086  |
      +----------------+--------------------------+-----------+
      | 517            | BGP Confederation Member | RFC 9086  |
      +----------------+--------------------------+-----------+

              Table 4: BGP-LS Descriptor TLV Code Points

And the Link Attribute ones are:

            +================+==============+===========+
            | TLV Code Point | Description  | Reference |
            +================+==============+===========+
            | 1101           | PeerNode SID | RFC 9086  |
            +----------------+--------------+-----------+
            | 1102           | PeerAdj SID  | RFC 9086  |
            +----------------+--------------+-----------+
            | 1103           | PeerSet SID  | RFC 9086  |
            +----------------+--------------+-----------+

              Table 5: BGP-LS Attribute TLV Code Points

7. Manageability Considerations 🌸

okay this part is all about how you actually keep things running smoothly without things going off the rails 🙈 The new extensions in here basically extend the existing IGP topology stuff that BGP-LS already distributes [RFC7752] by adding support for BGP peering topology too. So Section 6 of [RFC7752] (Manageability Considerations) applies to these new extensions as well, bestie, no extra work needed 🫶

The malformed Link-State NLRI and BGP-LS Attribute tests for syntactic checks in Section 6.2.2 of [RFC7752] (Fault Management) now cover the TLVs defined in this document too 🔥 The semantic or content checking, meaning whether a TLV makes sense and matches its BGP-LS NLRI types or Attributes, is left to the consumer of the BGP-LS information (like an app or a controller) and NOT the BGP protocol itself 💀 That's a consumer problem, not a BGP problem.

A consumer grabs this info from a BGP Speaker over a BGP-LS session (see Sections 1 and 2 of [RFC7752]) 🦋 How the consumer handles semantic or content errors depends on what its application is doing, so that's totally out of scope for this doc ✨ It may be expected that an error in the NLRI Descriptor TLVs makes that specific NLRI update unusable, so the update gets thrown out along with an error log 🌈 Meanwhile, an error in the Attribute TLVs only nukes that one attribute, and it gets dropped with an error log too 🍓

The operator MUST be provided with the options of configuring, enabling, and disabling the advertisement of each of the PeerNode SID, PeerAdj SID, and PeerSet SID, as well as control over which information gets advertised to which internal or external peer. This is not different from what a BGP speaker already needs in terms of information origination and advertisement 👑

BGP Peering Segments are tied to the normal BGP routing peering sessions 💜 But the peering info and the Peering Segments themselves get advertised over a separate BGP-LS peering session 🎀 It's expected that this isolation, as described in [RFC7752], is followed when advertising BGP peering topology info via BGP-LS ✨

BGP-EPE gives you the power to instantiate an SR path that engineers a flow out through an egress BGP router to a specific peer 🔥 It skips the normal BGP best-path routing for that flow and any routing policies set up in BGP on that egress router 😭 Like with any traffic-engineering solution, the controller or app running the policy has to make sure there's no looping or misrouting of traffic 💅 Traffic counters for the MPLS label of the BGP Peering SID on the router show what's being forwarded along that specific EPE path 🧚 Watching those counters and the flows hitting the matching MPLS forwarding entry can help you spot problems with traffic engineering over EPE paths 🌸 Errors when encoding or decoding the SR info in the TLVs from this document might mean a Centralized EPE Controller can't get that info, or gets incorrect info 🙈 That could stop the controller from doing its SR-based optimization, or make it do it in weird, inconsistent ways 💀 How apps like that controller handle those errors is implementation specific and out of scope for this doc 🫶

8. Security Considerations 🔐

this section is serious business, bestie, so no skipping 💀

[RFC7752] defines the BGP-LS NLRI that the extensions in this document apply to 🔥 Section 8 of [RFC7752] also applies to these extensions 👑 The procedures and new TLVs defined here don't, by themselves, change the BGP-LS security model discussed in [RFC7752] 🦋

BGP-EPE lets you engineer traffic as it leaves the administrative domain through an egress BGP router 😭 So you really have to make sure the BGP peering info collected via BGP-LS only goes to specific consumers, and does so securely 🚨 Segment Routing operates within a trusted domain [RFC8402], and its security considerations apply to BGP Peering Segments too 🌈 The BGP-EPE policies are expected to be used entirely within this trusted SR domain, like between multiple AS/domains inside a single provider network 🧚

Also, isolating BGP-LS peering sessions is required 💖 It makes sure BGP-LS topology info, including the newly added BGP peering topology, doesn't get advertised to an external BGP peering session outside an administrative domain 💅

9. References 📚

9.1. Normative References 💜

these are the must-reads 🎀

   [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>.

   [RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 5065,
              DOI 10.17487/RFC5065, August 2007,
              <https://www.rfc-editor.org/info/rfc5065>.

   [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>.

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <https://www.rfc-editor.org/info/rfc7752>.

   [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>.

   [RFC9085]  Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler,
              H., and M. Chen, "Border Gateway Protocol - Link State
              (BGP-LS) Extensions for Segment Routing", RFC 9085,
              DOI 10.17487/RFC9085, August 2021,
              <https://www.rfc-editor.org/info/rfc9085>.

9.2. Informative References 🧚

these ones are good to know, but they're not strictly required reading 🌸

   [BGPLS-SRV6]
              Dawra, G., Filsfils, C., Talaulikar, K., Chen, M.,
              Bernier, D., and B. Decraene, "BGP Link State Extensions
              for SRv6", Work in Progress, Internet-Draft, draft-ietf-
              idr-bgpls-srv6-ext-08, 8 June 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-idr-
              bgpls-srv6-ext-08>.

   [RFC9087]  Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
              and D. Afanasiev, "Segment Routing Centralized BGP Egress
              Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
              2021, <https://www.rfc-editor.org/info/rfc9087>.

   [SR-POLICY]
              Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and
              P. Mattes, "Segment Routing Policy Architecture", Work in
              Progress, Internet-Draft, draft-ietf-spring-segment-
              routing-policy-13, 28 May 2021,
              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
              segment-routing-policy-13>.

Acknowledgements 💖

the authors gave a big shoutout to Jakob Heitz, Howard Yang, Hannes Gredler, Peter Psenak, Arjun Sreekantiah, and Bruno Decraene for their feedback and comments 🫶 Susan Hares made the document way clearer with her big contributions during her shepherd's review 👑 And Alvaro Retana gets a huge thank-you for his extensive review and comments, which helped fix issues and make the doc better 🔥

Contributors 🌈

   Mach(Guoyi) Chen
   Huawei Technologies
   China

   Email: mach.chen@huawei.com


   Acee Lindem
   Cisco Systems Inc.
   United States of America

   Email: acee@cisco.com

Authors' Addresses ✨

   Stefano Previdi
   Huawei Technologies

   Email: stefano@previdi.net


   Ketan Talaulikar (editor)
   Cisco Systems, Inc.
   India

   Email: ketant@cisco.com


   Clarence Filsfils
   Cisco Systems, Inc.
   Brussels
   Belgium

   Email: cfilsfil@cisco.com


   Keyur Patel
   Arrcus, Inc.

   Email: Keyur@arrcus.com


   Saikat Ray
   Individual

   Email: raysaikat@gmail.com


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China

   Email: jie.dong@huawei.com
📦 where this page comes from