diff options
Diffstat (limited to 'doc/rfc/rfc9087.txt')
| -rw-r--r-- | doc/rfc/rfc9087.txt | 902 |
1 files changed, 902 insertions, 0 deletions
diff --git a/doc/rfc/rfc9087.txt b/doc/rfc/rfc9087.txt new file mode 100644 index 0000000..33ec8b3 --- /dev/null +++ b/doc/rfc/rfc9087.txt @@ -0,0 +1,902 @@ + + + + +Internet Engineering Task Force (IETF) C. Filsfils, Ed. +Request for Comments: 9087 S. Previdi +Category: Informational G. Dawra, Ed. +ISSN: 2070-1721 Cisco Systems, Inc. + E. Aries + Juniper Networks + D. Afanasiev + Yandex + August 2021 + + + Segment Routing Centralized BGP Egress Peer Engineering + +Abstract + + Segment Routing (SR) leverages source routing. A node steers a + packet through a controlled set of instructions, called segments, by + prepending the packet with an SR header. A segment can represent any + instruction, topological or service based. SR allows for the + enforcement of a flow through any topological path while maintaining + per-flow state only at the ingress node of the SR domain. + + The Segment Routing architecture can be directly applied to the MPLS + data plane with no change on the forwarding plane. It requires a + minor extension to the existing link-state routing protocols. + + This document illustrates the application of Segment Routing to solve + the BGP Egress Peer Engineering (BGP-EPE) requirement. The SR-based + BGP-EPE solution allows a centralized (Software-Defined Networking, + or SDN) controller to program any egress peer policy at ingress + border routers or at hosts within the domain. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see 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/rfc9087. + +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 + 1.1. Problem Statement + 1.2. Requirements Language + 2. BGP Peering Segments + 3. Distribution of Topology and TE Information Using BGP-LS + 3.1. PeerNode SID to D + 3.2. PeerNode SID to E + 3.3. PeerNode SID to F + 3.4. First PeerAdj to F + 3.5. Second PeerAdj to F + 3.6. Fast Reroute (FRR) + 4. BGP-EPE Controller + 4.1. Valid Paths from Peers + 4.2. Intra-Domain Topology + 4.3. External Topology + 4.4. SLA Characteristics of Each Peer + 4.5. Traffic Matrix + 4.6. Business Policies + 4.7. BGP-EPE Policy + 5. Programming an Input Policy + 5.1. At a Host + 5.2. At a Router - SR Traffic-Engineering Tunnel + 5.3. At a Router - Unicast Route Labeled Using BGP (RFC 8277) + 5.4. At a Router - VPN Policy Route + 6. IPv6 Data Plane + 7. Benefits + 8. IANA Considerations + 9. Manageability Considerations + 10. Security Considerations + 11. References + 11.1. Normative References + 11.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + The document is structured as follows: + + * Section 1 states the BGP-EPE problem statement and provides the + key references. + + * Section 2 defines the different BGP Peering Segments and the + semantic associated to them. + + * Section 3 describes the automated allocation of BGP Peering + Segment-IDs (SIDs) by the BGP-EPE-enabled egress border router and + the automated signaling of the external peering topology and the + related BGP Peering SIDs to the collector [RFC9086]. + + * Section 4 overviews the components of a centralized BGP-EPE + controller. The definition of the BGP-EPE controller is outside + the scope of this document. + + * Section 5 overviews the methods that could be used by the + centralized BGP-EPE controller to implement a BGP-EPE policy at an + ingress border router or at a source host within the domain. The + exhaustive definition of all the means to program a BGP-EPE input + policy is outside the scope of this document. + + For editorial reasons, the solution is described with IPv6 addresses + and MPLS SIDs. This solution is equally applicable to IPv4 with MPLS + SIDs and also to IPv6 with native IPv6 SIDs. + +1.1. Problem Statement + + The BGP-EPE problem statement is defined in [RFC7855]. + + A centralized controller should be able to instruct an ingress + Provider Edge (PE) router or a content source within the domain to + use a specific egress PE and a specific external interface/neighbor + to reach a particular destination. + + Let's call this solution "BGP-EPE" for "BGP Egress Peer Engineering". + The centralized controller is called the "BGP-EPE controller". The + egress border router where the BGP-EPE traffic steering functionality + is implemented is called a BGP-EPE-enabled border router. The input + policy programmed at an ingress border router or at a source host is + called a BGP-EPE policy. + + The requirements that have motivated the solution described in this + document are listed here below: + + * The solution MUST apply to the Internet use case where the + Internet routes are assumed to use IPv4 unlabeled or IPv6 + unlabeled. It is not required to place the Internet routes in a + VPN Routing and Forwarding (VRF) instance and allocate labels on a + per-route or per-path basis. + + * The solution MUST support any deployed Internal BGP (iBGP) schemes + (Route Reflectors (RRs), confederations, or iBGP full meshes). + + * The solution MUST be applicable to both routers with external and + internal peers. + + * The solution should minimize the need for new BGP capabilities at + the ingress PEs. + + * The solution MUST accommodate an ingress BGP-EPE policy at an + ingress PE or directly at a source within the domain. + + * The solution MAY support automated Fast Reroute (FRR) and fast + convergence mechanisms. + + The following reference diagram is used throughout this document. + + +---------+ +------+ + | | | | + | H B------D G + | | +---/| AS 2 |\ +------+ + | |/ +------+ \ | |---L/8 + A AS1 C---+ \| | + | |\\ \ +------+ /| AS 4 |---M/8 + | | \\ +-E |/ +------+ + | X | \\ | K + | | +===F AS 3 | + +---------+ +------+ + + Figure 1: Reference Diagram + + IP addressing: + + * C's interface to D: 2001:db8:cd::c/64, D's interface: + 2001:db8:cd::d/64 + + * C's interface to E: 2001:db8:ce::c/64, E's interface: + 2001:db8:ce::e/64 + + * C's upper interface to F: 2001:db8:cf1::c/64, F's interface: + 2001:db8:cf1::f/64 + + * C's lower interface to F: 2001:db8:cf2::c/64, F's interface: + 2001:db8:cf2::f/64 + + * BGP router-ID of C: 192.0.2.3 + + * BGP router-ID of D: 192.0.2.4 + + * BGP router-ID of E: 192.0.2.5 + + * BGP router-ID of F: 192.0.2.6 + + * Loopback of F used for External BGP (eBGP) multi-hop peering to C: + 2001:db8:f::f/128 + + * C's loopback is 2001:db8:c::c/128 with SID 64 + + C's BGP peering: + + * Single-hop eBGP peering with neighbor 2001:db8:cd::d (D) + + * Single-hop eBGP peering with neighbor 2001:db8:ce::e (E) + + * Multi-hop eBGP peering with F on IP address 2001:db8:f::f (F) + + C's resolution of the multi-hop eBGP session to F: + + * Static route to 2001:db8:f::f/128 via 2001:db8:cf1::f + + * Static route to 2001:db8:f::f/128 via 2001:db8:cf2::f + + C is configured with a local policy that defines a BGP PeerSet as the + set of peers (2001:db8:ce::e for E and 2001:db8:f::f for F). + + X is the BGP-EPE controller within the AS1 domain. + + H is a content source within the AS1 domain. + +1.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. + +2. BGP Peering Segments + + As defined in [RFC8402], certain segments are defined by a BGP-EPE- + capable node and correspond to their attached peers. These segments + are called BGP Peering Segments or BGP Peering SIDs. They enable the + expression of source-routed inter-domain paths. + + An ingress border router of an AS may compose a list of segments to + steer a flow along a selected path within the AS, towards a selected + egress border router C of the AS and through a specific peer. At + minimum, a BGP Egress Peer Engineering policy applied at an ingress + EPE involves two segments: the Node SID of the chosen egress EPE and + then the BGP Peering Segment for the chosen egress EPE peer or + peering interface. + + [RFC8402] defines three types of BGP Peering Segments/SIDs: PeerNode + SID, PeerAdj SID, and PeerSet SID. + + Peer Node Segment: A segment describing a peer, including the SID + (PeerNode SID) allocated to it + + Peer Adjacency Segment: A segment describing a link, including + the SID (PeerAdj SID) allocated to it + + Peer Set Segment: A segment describing a link or a node that is + part of the set, including the SID (PeerSet SID) allocated to + the set + +3. Distribution of Topology and TE Information Using BGP-LS + + In ships-in-the-night mode with respect to the pre-existing iBGP + design, a Border Gateway Protocol - Link State (BGP-LS) [RFC7752] + session is established between the BGP-EPE-enabled border router and + the BGP-EPE controller. + + As a result of its local configuration and according to the behavior + described in [RFC9086], Node C allocates the following BGP Peering + Segments [RFC8402]: + + * A PeerNode segment for each of its defined peers (D: 1012, E: 1022 + and F: 1052). + + * A PeerAdj segment for each recursing interface to a multi-hop peer + (e.g., the upper and lower interfaces from C to F in Figure 1). + + * A PeerSet segment to the set of peers (E and F). In this case, + the PeerSet represents a set of peers (E, F) belonging to the same + AS (AS 3). + + C programs its forwarding table accordingly: + + +================+===========+===============================+ + | Incoming Label | Operation | Outgoing Interface | + +================+===========+===============================+ + | 1012 | POP | link to D | + +----------------+-----------+-------------------------------+ + | 1022 | POP | link to E | + +----------------+-----------+-------------------------------+ + | 1032 | POP | upper link to F | + +----------------+-----------+-------------------------------+ + | 1042 | POP | lower link to F | + +----------------+-----------+-------------------------------+ + | 1052 | POP | load balance on any link to F | + +----------------+-----------+-------------------------------+ + | 1060 | POP | load balance on any link to E | + | | | or to F | + +----------------+-----------+-------------------------------+ + + Table 1 + + C signals each related BGP-LS instance of Network Layer Reachability + Information (NLRI) to the BGP-EPE controller. Each such BGP-LS route + is described in the following subsections according to the encoding + details defined in [RFC9086]. + +3.1. PeerNode SID to D + + Descriptors: + + * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): + 192.0.2.3, AS1, 1000 + + * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.4, AS2 + + * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): + 2001:db8:cd::c, 2001:db8:cd::d + + Attributes: + + * PeerNode SID: 1012 + +3.2. PeerNode SID to E + + Descriptors: + + * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): + 192.0.2.3, AS1, 1000 + + * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.5, AS3 + + * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): + 2001:db8:ce::c, 2001:db8:ce::e + + Attributes: + + * PeerNode SID: 1022 + + * PeerSetSID: 1060 + + * Link Attributes: see Section 3.3.2 of [RFC7752] + +3.3. PeerNode SID to F + + Descriptors: + + * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): + 192.0.2.3, AS1, 1000 + + * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 + + * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): + 2001:db8:c::c, 2001:db8:f::f + + Attributes: + + * PeerNode SID: 1052 + + * PeerSetSID: 1060 + +3.4. First PeerAdj to F + + Descriptors: + + * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): + 192.0.2.3, AS1, 1000 + + * Remote Node Descriptors (BGP router-ID, ASN): 192.0.2.6, AS3 + + * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): + 2001:db8:cf1::c, 2001:db8:cf1::f + + Attributes: + + * PeerAdj-SID: 1032 + + * Link Attributes: see Section 3.3.2 of [RFC7752] + +3.5. Second PeerAdj to F + + Descriptors: + + * Local Node Descriptors (BGP router-ID, ASN, BGP-LS Identifier): + 192.0.2.3 , AS1, 1000 + + * Remote Node Descriptors (peer router-ID, peer ASN): 192.0.2.6, AS3 + + * Link Descriptors (IPv6 Interface Address, IPv6 Neighbor Address): + 2001:db8:cf2::c, 2001:db8:cf2::f + + Attributes: + + * PeerAdj-SID: 1042 + + * Link Attributes: see Section 3.3.2 of [RFC7752] + +3.6. Fast Reroute (FRR) + + A BGP-EPE-enabled border router MAY allocate an FRR backup entry on a + per-BGP-Peering-SID basis. One example is as follows: + + * PeerNode SID + + 1. If multi-hop, back up via the remaining PeerADJ SIDs (if + available) to the same peer. + + 2. Else, back up via another PeerNode SID to the same AS. + + 3. Else, pop the PeerNode SID and perform an IP lookup. + + * PeerAdj SID + + 1. If to a multi-hop peer, back up via the remaining PeerADJ SIDs + (if available) to the same peer. + + 2. Else, back up via a PeerNode SID to the same AS. + + 3. Else, pop the PeerNode SID and perform an IP lookup. + + * PeerSet SID + + 1. Back up via remaining PeerNode SIDs in the same PeerSet. + + 2. Else, pop the PeerNode SID and IP lookup. + + Let's illustrate different types of possible backups using the + reference diagram and considering the Peering SIDs allocated by C. + + PeerNode SID 1052, allocated by C for peer F: + + * Upon the failure of the upper connected link CF, C can reroute all + the traffic onto the lower CF link to the same peer (F). + + PeerNode SID 1022, allocated by C for peer E: + + * Upon the failure of the connected link CE, C can reroute all the + traffic onto the link to PeerNode SID 1052 (F). + + PeerNode SID 1012, allocated by C for peer D: + + * Upon the failure of the connected link CD, C can pop the PeerNode + SID and look up the IP destination address in its FIB and route + accordingly. + + PeerSet SID 1060, allocated by C for the set of peers E and F: + + * Upon the failure of a connected link in the group, the traffic to + PeerSet SID 1060 is rerouted on any other member of the group. + + For specific business reasons, the operator might not want the + default FRR behavior applied to a PeerNode SID or any of its + dependent PeerADJ SIDs. + + The operator should be able to associate a specific backup PeerNode + SID for a PeerNode SID; e.g., 1022 (E) must be backed up by 1012 (D), + which overrules the default behavior that would have preferred F as a + backup for E. + +4. BGP-EPE Controller + + In this section, Let's provide a non-exhaustive set of inputs that a + BGP-EPE controller would likely collect such as to perform the BGP- + EPE policy decision. + + The exhaustive definition is outside the scope of this document. + +4.1. Valid Paths from Peers + + The BGP-EPE controller should collect all the BGP paths (i.e., IP + destination prefixes) advertised by all the BGP-EPE-enabled border + routers. + + This could be realized by setting an iBGP session with the BGP-EPE- + enabled border router, with the router configured to advertise all + paths using BGP ADD-PATH [RFC7911] and the original next hop + preserved. + + In this case, C would advertise the following Internet routes to the + BGP-EPE controller: + + * NLRI <2001:db8:abcd::/48>, next hop 2001:db8:cd::d, AS Path + {AS 2, 4} + + - X (i.e., the BGP-EPE controller) knows that C receives a path + to 2001:db8:abcd::/48 via neighbor 2001:db8:cd::d of AS2. + + * NLRI <2001:db8:abcd::/48>, next hop 2001:db8:ce::e, AS Path + {AS 3, 4} + + - X knows that C receives a path to 2001:db8:abcd::/48 via + neighbor 2001:db8:ce::e of AS2. + + * NLRI <2001:db8:abcd::/48>, next hop 2001:db8:f::f, AS Path + {AS 3, 4} + + - X knows that C has an eBGP path to 2001:db8:abcd::/48 via AS3 + via neighbor 2001:db8:f::f. + + An alternative option would be for a BGP-EPE collector to use the BGP + Monitoring Protocol (BMP) [RFC7854] to track the Adj-RIB-In of BGP- + EPE-enabled border routers. + +4.2. Intra-Domain Topology + + The BGP-EPE controller should collect the internal topology and the + related IGP SIDs. + + This could be realized by collecting the IGP Link-State Database + (LSDB) of each area or running a BGP-LS session with a node in each + IGP area. + +4.3. External Topology + + Thanks to the collected BGP-LS routes described in Section 3, the + BGP-EPE controller is able to maintain an accurate description of the + egress topology of Node C. Furthermore, the BGP-EPE controller is + able to associate BGP Peering SIDs to the various components of the + external topology. + +4.4. SLA Characteristics of Each Peer + + The BGP-EPE controller might collect Service Level Agreement (SLA) + characteristics across peers. This requires a BGP-EPE solution, as + the SLA probes need to be steered via non-best-path peers. + + Unidirectional SLA monitoring of the desired path is likely required. + This might be possible when the application is controlled at the + source and the receiver side. Unidirectional monitoring dissociates + the SLA characteristic of the return path (which cannot usually be + controlled) from the forward path (the one of interest for pushing + content from a source to a consumer and the one that can be + controlled). + + Alternatively, Metric Extensions, as defined in [RFC8570], could also + be advertised using BGP-LS [RFC8571]. + +4.5. Traffic Matrix + + The BGP-EPE controller might collect the traffic matrix to its peers + or the final destinations. IP Flow Information Export (IPFIX) + [RFC7011] is a likely option. + + An alternative option consists of collecting the link utilization + statistics of each of the internal and external links, also available + in the current definition in [RFC7752]. + +4.6. Business Policies + + The BGP-EPE controller should be configured or collect business + policies through any desired mechanisms. These mechanisms by which + these policies are configured or collected are outside the scope of + this document. + +4.7. BGP-EPE Policy + + On the basis of all these inputs (and likely others), the BGP-EPE + controller decides to steer some demands away from their best BGP + path. + + The BGP-EPE policy is likely expressed as a two-entry segment list + where the first element is the IGP Prefix-SID of the selected egress + border router and the second element is a BGP Peering SID at the + selected egress border router. + + A few examples are provided hereafter: + + * Prefer egress PE C and peer AS AS2: {64, 1012}. "64" being the SID + of PE C as defined in Section 1.1. + + * Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:ce::e, + {64, 1022}. + + * Prefer egress PE C and peer AS AS3 via eBGP peer 2001:db8:f::f, + {64, 1052}. + + * Prefer egress PE C and peer AS AS3 via interface 2001:db8:cf2::f + of multi-hop eBGP peer 2001:db8:f::f, {64, 1042}. + + * Prefer egress PE C and any interface to any peer in the group + 1060: {64, 1060}. + + Note that the first SID could be replaced by a list of segments. + This is useful when an explicit path within the domain is required + for traffic-engineering purposes. For example, if the Prefix-SID of + Node B is 60 and the BGP-EPE controller would like to steer the + traffic from A to C via B then through the external link to peer D, + then the segment list would be {60, 64, 1012}. + +5. Programming an Input Policy + + The detailed/exhaustive description of all the means to implement a + BGP-EPE policy are outside the scope of this document. A few + examples are provided in this section. + +5.1. At a Host + + A static IP/MPLS route can be programmed at the host H. The static + route would define a destination prefix, a next hop, and a label + stack to push. Assuming the same Segment Routing Global Block + (SRGB), at least on all access routers connecting the hosts, the same + policy can be programmed across all hosts, which is convenient. + +5.2. At a Router - SR Traffic-Engineering Tunnel + + The BGP-EPE controller can configure the ingress border router with + an SR traffic-engineering tunnel T1 and a steering policy S1, which + causes a certain class of traffic to be mapped on the tunnel T1. + + The tunnel T1 would be configured to push the required segment list. + + The tunnel and the steering policy could be configured via multiple + means. A few examples are given below: + + * The Path Computation Element Communication Protocol (PCEP) + according to [RFC8664] and [RFC8281] + + * NETCONF [RFC6241] + + * Other static or ephemeral APIs + + Example: at router A (Figure 1). + + Tunnel T1: push {64, 1042} + IP route L/8 set next-hop T1 + +5.3. At a Router - Unicast Route Labeled Using BGP (RFC 8277) + + The BGP-EPE controller could build a unicast route labeled using BGP + [RFC8277] (from scratch) and send it to the ingress router. + + Such a route would require the following: + + NLRI + the destination prefix to engineer (e.g., L/8) + + Next Hop + the selected egress border router: C + + Label + the selected egress peer: 1042 + + Autonomous System (AS) path + the selected valid AS path + + Some BGP policy to ensure it will be selected as best by the ingress + router. Note that as discussed in Section 5 of [RFC8277], the + comparison of a labeled and unlabeled unicast BGP route is + implementation dependent and hence may require an implementation- + specific policy on each ingress router. + + This unicast route labeled using BGP [RFC8277] "overwrites" an + equivalent or less-specific "best path". As the best path is + changed, this BGP-EPE input policy option may influence the path + propagated to the upstream peer/customers. Indeed, implementations + treating the SAFI-1 and SAFI-4 routes for a given prefix as + comparable would trigger a BGP WITHDRAW of the SAFI-1 route to their + BGP upstream peers. + +5.4. At a Router - VPN Policy Route + + The BGP-EPE controller could build a VPNv4 route (from scratch) and + send it to the ingress router. + + Such a route would require the following: + + NLRI + the destination prefix to engineer: e.g., L/8 + + Next Hop + the selected egress border router: C + + Label + the selected egress peer: 1042 + + Route-Target + the selected appropriate VRF instance at the ingress router + + AS path + the selected valid AS path + + Some BGP policy to ensure it will be selected as best by the ingress + router in the related VRF instance. + + The related VRF instance must be preconfigured. A VRF fallback to + the main FIB might be beneficial to avoid replicating all the + "normal" Internet paths in each VRF instance. + +6. IPv6 Data Plane + + The described solution is applicable to IPv6, either with MPLS-based + or IPv6-native segments. In both cases, the same three steps of the + solution are applicable: + + * BGP-LS-based signaling of the external topology and BGP Peering + Segments to the BGP-EPE controller. + + * Collecting, by the BGP-EPE controller, various inputs to come up + with a policy decision. + + * Programming at an ingress router or source host of the desired + BGP-EPE policy, which consists of a list of segments to push on a + defined traffic class. + +7. Benefits + + The BGP-EPE solutions described in this document have the following + benefits: + + * No assumption on the iBGP design within AS1. + + * Next-hop-self on the Internet routes propagated to the ingress + border routers is possible. This is a common design rule to + minimize the number of IGP routes and to avoid importing external + churn into the internal routing domain. + + * Consistent support for traffic engineering within the domain and + at the external edge of the domain. + + * Support for both host and ingress border router BGP-EPE policy + programming. + + * BGP-EPE functionality is only required on the BGP-EPE-enabled + egress border router and the BGP-EPE controller; an ingress policy + can be programmed at the ingress border router without any new + functionality. + + * Ability to deploy the same input policy across hosts connected to + different routers (assuming the global property of IGP Prefix- + SIDs). + +8. IANA Considerations + + This document has no IANA actions. + +9. Manageability Considerations + + The BGP-EPE use case described in this document requires BGP-LS + [RFC7752] extensions that are described in [RFC9086] and that + consists of additional BGP-LS descriptors and TLVs. Manageability + functions of BGP-LS, described in [RFC7752], also apply to the + extensions required by the EPE use case. + + Additional manageability considerations are described in [RFC9086]. + +10. Security Considerations + + [RFC7752] defines BGP-LS NLRI instances and their associated security + aspects. + + [RFC9086] defines the BGP-LS extensions required by the BGP-EPE + mechanisms described in this document. BGP-EPE BGP-LS extensions + also include the related security. + +11. References + +11.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>. + + [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>. + + [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., + Ray, S., and J. Dong, "Border Gateway Protocol - Link + State (BGP-LS) Extensions for Segment Routing BGP Egress + Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August + 2021, <https://www.rfc-editor.org/info/rfc9086>. + +11.2. Informative References + + [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., + and A. Bierman, Ed., "Network Configuration Protocol + (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, + <https://www.rfc-editor.org/info/rfc6241>. + + [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, + "Specification of the IP Flow Information Export (IPFIX) + Protocol for the Exchange of Flow Information", STD 77, + RFC 7011, DOI 10.17487/RFC7011, September 2013, + <https://www.rfc-editor.org/info/rfc7011>. + + [RFC7854] Scudder, J., Ed., Fernando, R., and S. Stuart, "BGP + Monitoring Protocol (BMP)", RFC 7854, + DOI 10.17487/RFC7854, June 2016, + <https://www.rfc-editor.org/info/rfc7854>. + + [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., + Litkowski, S., Horneffer, M., and R. Shakir, "Source + Packet Routing in Networking (SPRING) Problem Statement + and Requirements", RFC 7855, DOI 10.17487/RFC7855, May + 2016, <https://www.rfc-editor.org/info/rfc7855>. + + [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, + "Advertisement of Multiple Paths in BGP", RFC 7911, + DOI 10.17487/RFC7911, July 2016, + <https://www.rfc-editor.org/info/rfc7911>. + + [RFC8277] Rosen, E., "Using BGP to Bind MPLS Labels to Address + Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, + <https://www.rfc-editor.org/info/rfc8277>. + + [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path + Computation Element Communication Protocol (PCEP) + Extensions for PCE-Initiated LSP Setup in a Stateful PCE + Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, + <https://www.rfc-editor.org/info/rfc8281>. + + [RFC8570] Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward, + D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) + Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March + 2019, <https://www.rfc-editor.org/info/rfc8570>. + + [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and + C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of + IGP Traffic Engineering Performance Metric Extensions", + RFC 8571, DOI 10.17487/RFC8571, March 2019, + <https://www.rfc-editor.org/info/rfc8571>. + + [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., + and J. Hardwick, "Path Computation Element Communication + Protocol (PCEP) Extensions for Segment Routing", RFC 8664, + DOI 10.17487/RFC8664, December 2019, + <https://www.rfc-editor.org/info/rfc8664>. + +Acknowledgements + + The authors would like to thank Acee Lindem for his comments and + contribution. + +Contributors + + Daniel Ginsburg substantially contributed to the content of this + document. + +Authors' Addresses + + Clarence Filsfils (editor) + Cisco Systems, Inc. + Brussels + Belgium + + Email: cfilsfil@cisco.com + + + Stefano Previdi + Cisco Systems, Inc. + Italy + + Email: stefano@previdi.net + + + Gaurav Dawra (editor) + Cisco Systems, Inc. + United States of America + + Email: gdawra.ietf@gmail.com + + + Ebben Aries + Juniper Networks + 1133 Innovation Way + Sunnyvale, CA 94089 + United States of America + + Email: exa@juniper.net + + + Dmitry Afanasiev + Yandex + Russian Federation + + Email: fl0w@yandex-team.ru |