diff options
Diffstat (limited to 'doc/rfc/rfc9086.txt')
| -rw-r--r-- | doc/rfc/rfc9086.txt | 840 |
1 files changed, 840 insertions, 0 deletions
diff --git a/doc/rfc/rfc9086.txt b/doc/rfc/rfc9086.txt new file mode 100644 index 0000000..cac233d --- /dev/null +++ b/doc/rfc/rfc9086.txt @@ -0,0 +1,840 @@ + + + + +Internet Engineering Task Force (IETF) S. Previdi +Request for Comments: 9086 Huawei Technologies +Category: Standards Track K. Talaulikar, Ed. +ISSN: 2070-1721 C. Filsfils + Cisco Systems, Inc. + K. Patel + Arrcus, Inc. + S. Ray + Individual + J. Dong + Huawei Technologies + August 2021 + + + Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment + Routing BGP Egress Peer Engineering + +Abstract + + 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 segment can represent any instruction, + topological or service based. SR segments allow steering a flow + through any topological path and service chain while maintaining per- + flow state only at the ingress node of the SR domain. + + This document describes an extension to Border Gateway Protocol - + Link State (BGP-LS) for advertisement of 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 Notice + + 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) leverages source routing. 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 allows to enforce a flow through any topological path or + service function while maintaining 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 be directly applied to either an MPLS data plane (SR-MPLS) + with no change on the forwarding plane or to 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] for advertising BGP peering segments + from a BGP node along with its peering topology information (i.e., + its peers, interfaces, and peering Autonomous Systems (ASes)) 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. This use case comprises a centralized controller + that learns the BGP Peering SIDs via BGP-LS and then uses this + information to program a BGP-EPE policy at any node in the domain to + perform traffic steering 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 to facilitate advertising + BGP-LS Link NLRI to represent the BGP peering topology. Further, it + specifies the BGP-LS Attribute TLVs for advertisement of the BGP + Peering Segments (i.e., PeerNode SID, PeerAdj SID, and PeerSet SID) + to be advertised in the same BGP-LS Link NLRI. + +2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +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. + + An ingress border router of an AS may compose a list of SIDs to steer + a flow along a selected path within the AS, towards a selected egress + border router C of the AS, and to a specific EBGP peer. 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 in order to group EPE resources 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. + + While an egress point in a topology usually refers to EBGP sessions + between external peers, there's nothing in the extensions defined in + this document that would prevent the use of these extensions 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. As such, 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 since the purpose of BGP + Peering SID is to steer traffic to those specific peers. Thus, the + applicability for IBGP peering may 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 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 are described in + [RFC9087]. + +4. BGP-LS NLRI Advertisement for BGP Protocol + + This section describes 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 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 use of a new Protocol-ID allows separation and differentiation + between 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 their Peering Segments are + advertised using BGP-LS Link NLRI type with the Protocol-ID set to + BGP. BGP-LS Link NLRI type uses the Descriptor TLVs and BGP-LS + Attribute TLVs as defined in [RFC7752]. In order to correctly + describe BGP nodes, new TLVs are defined in this section. + + [RFC7752] defines 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 + + Two new Node Descriptor TLVs are defined in this document: + + * 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 distributing BGP information: + + * 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. + + Note that Section 2.1 of [RFC6286] requires the BGP identifier + (Router-ID) to be unique within an Autonomous System and non-zero. + Therefore, the <ASN, BGP Router-ID> tuple is globally unique. Their + use in the Node Descriptor helps map Link-State NLRIs with BGP + protocol-ID to a unique 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 information: + + * 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 + + The following Node Descriptor TLVs MAY be included in BGP-LS NLRI as + Local Node Descriptors when distributing BGP information: + + * 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 information: + + * 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 + + This section defines the BGP-LS Attributes corresponding to the + following 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 defined for use with + BGP-LS Link NLRI for advertising 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 have the same format + as defined below: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Weight | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label/Index (variable) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: BGP Peering SIDs TLV Format + + * Type: 1101, 1102, or 1103 as listed in Table 2 + + * Length: variable. Valid values are either 7 or 8 based 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. + + 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 in order to advertise the + characteristics of the peering link, e.g., 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. + +6. IANA Considerations + + This document defines: + + * 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 + + This document defines a new value in the registry "BGP-LS Protocol- + IDs": + + +=============+==================================+===========+ + | Protocol-ID | NLRI information source protocol | Reference | + +=============+==================================+===========+ + | 7 | BGP | RFC 9086 | + +-------------+----------------------------------+-----------+ + + Table 3: BGP-LS Protocol-ID + +6.2. Node Descriptors and Link Attribute TLVs + + This document defines five new TLVs in the registry "BGP-LS Node + Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs": + + * Two new Node Descriptor TLVs + + * Three new Link Attribute TLVs + + All five of the new code points are in the same registry: "BGP-LS + Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute + TLVs". + + The following new Node Descriptor TLVs are defined: + + +================+==========================+===========+ + | 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 + + The following new Link Attribute TLVs are defined: + + +================+==============+===========+ + | 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 + + The new protocol extensions introduced in this document augment the + existing IGP topology information BGP-LS distribution [RFC7752] by + adding support for distribution of BGP peering topology information. + As such, Section 6 of [RFC7752] (Manageability Considerations) + applies to these new extensions as well. + + Specifically, the malformed Link-State NLRI and BGP-LS Attribute + tests for syntactic checks in Section 6.2.2 of [RFC7752] (Fault + Management) now apply to the TLVs defined in this document. The + semantic or content checking for the TLVs specified in this document + and their association with the BGP-LS NLRI types or their associated + BGP-LS Attributes is left to the consumer of the BGP-LS information + (e.g., an application or a controller) and not the BGP protocol. + + A consumer of the BGP-LS information retrieves this information from + a BGP Speaker, over a BGP-LS session (refer to Sections 1 and 2 of + [RFC7752]). The handling of semantic or content errors by the + consumer would be dictated by the nature of its application usage and + is hence beyond the scope of this document. It may be expected that + an error detected in the NLRI Descriptor TLVs would result in that + specific NLRI update being unusable and hence its update to be + discarded along with an error log, whereas an error in Attribute TLVs + would result in only that specific attribute being discarded with an + error log. + + 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 of which + information is advertised to which internal or external peer. This + is not different from what is required by a BGP speaker in terms of + information origination and advertisement. + + BGP Peering Segments are associated with the normal BGP routing + peering sessions. However, the BGP peering information along with + these Peering Segments themselves are advertised via a distinct BGP- + LS peering session. It is expected that this isolation as described + in [RFC7752] is followed when advertising BGP peering topology + information via BGP-LS. + + BGP-EPE functionality enables the capability for instantiation of an + SR path for traffic engineering a flow via an egress BGP router to a + specific peer, bypassing the normal BGP best-path routing for that + flow and any routing policies implemented in BGP on that egress BGP + router. As with any traffic-engineering solution, the controller or + application implementing the policy needs to ensure that there is no + looping or misrouting of traffic. Traffic counters corresponding to + the MPLS label of the BGP Peering SID on the router would indicate + the traffic being forwarded based on the specific EPE path. + Monitoring these counters and the flows hitting the corresponding + MPLS forwarding entry would help identify issues, if any, with + traffic engineering over the EPE paths. Errors in the encoding or + decoding of the SR information in the TLVs defined in this document + may result in the unavailability of such information to a Centralized + EPE Controller or incorrect information being made available to it. + This may result in the controller not being able to perform the + desired SR-based optimization functionality or performing it in an + unexpected or inconsistent manner. The handling of such errors by + applications like such a controller may be implementation specific + and out of scope of this document. + +8. Security Considerations + + [RFC7752] defines BGP-LS NLRI to which the extensions defined in this + document apply. Section 8 of [RFC7752] also applies to these + extensions. The procedures and new TLVs defined in this document, by + themselves, do not affect the BGP-LS security model discussed in + [RFC7752]. + + BGP-EPE enables engineering of traffic when leaving the + administrative domain via an egress BGP router. Therefore, + precaution is necessary to ensure that the BGP peering information + collected via BGP-LS is limited to specific consumers in a secure + manner. Segment Routing operates within a trusted domain [RFC8402], + and its security considerations also apply to BGP Peering Segments. + The BGP-EPE policies are expected to be used entirely within this + trusted SR domain (e.g., between multiple AS/domains within a single + provider network). + + The isolation of BGP-LS peering sessions is also required to ensure + that BGP-LS topology information (including the newly added BGP + peering topology) is not advertised to an external BGP peering + session outside an administrative domain. + +9. References + +9.1. Normative References + + [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 + + [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 would like to thank Jakob Heitz, Howard Yang, Hannes + Gredler, Peter Psenak, Arjun Sreekantiah, and Bruno Decraene for + their feedback and comments. Susan Hares helped in improving the + clarity of the document with her substantial contributions during her + shepherd's review. The authors would also like to thank Alvaro + Retana for his extensive review and comments, which helped correct + issues and improve the document. + +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 |