Cisco Systems, Inc.

Brussels Belgium cfilsfil@cisco.com

Cisco Systems, Inc.

Italy stefano@previdi.net

Cisco Systems, Inc.

United States of America gdawra.ietf@gmail.com

Juniper Networks

1133 Innovation Way Sunnyvale CA 94089 United States of America exa@juniper.net

Yandex

Russian Federation fl0w@yandex-team.ru

RTG SPRING 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 .

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 () 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

• .  Introduction
  • .  Problem Statement
  • .  Requirements Language
• .  BGP Peering Segments
• .  Distribution of Topology and TE Information Using BGP-LS
  • .  PeerNode SID to D
  • .  PeerNode SID to E
  • .  PeerNode SID to F
  • .  First PeerAdj to F
  • .  Second PeerAdj to F
  • .  Fast Reroute (FRR)
• .  BGP-EPE Controller
  • .  Valid Paths from Peers
  • .  Intra-Domain Topology
  • .  External Topology
  • .  SLA Characteristics of Each Peer
  • .  Traffic Matrix
  • .  Business Policies
  • .  BGP-EPE Policy
• .  Programming an Input Policy
  • .  At a Host
  • .  At a Router - SR Traffic-Engineering Tunnel
  • .  At a Router - Unicast Route Labeled Using BGP (RFC 8277)
  • .  At a Router - VPN Policy Route
• .  IPv6 Data Plane
• .  Benefits
• .  IANA Considerations
• .  Manageability Considerations
• . Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Contributors
• Authors' Addresses

Introduction The document is structured as follows:

• states the BGP-EPE problem statement and provides the key references.
• defines the different BGP Peering Segments and the semantic associated to them.
• 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 .
• overviews the components of a centralized BGP-EPE controller. The definition of the BGP-EPE controller is outside the scope of this document.
• 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.

Problem Statement The BGP-EPE problem statement is defined in . 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.

Reference Diagram +---------+ +------+ | | | | | H B------D G | | +---/| AS 2 |\ +------+ | |/ +------+ \ | |---L/8 A AS1 C---+ \| | | |\\ \ +------+ /| AS 4 |---M/8 | | \\ +-E |/ +------+ | X | \\ | K | | +===F AS 3 | +---------+ +------+

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.

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 when, and only when, they appear in all capitals, as shown here.

BGP Peering Segments As defined in , 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. 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

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) 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 , Node C allocates the following BGP Peering Segments :

• 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 ).
• 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

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 .

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

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

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

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

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

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.

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.

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 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) to track the Adj-RIB-In of BGP-EPE-enabled border routers.

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.

External Topology Thanks to the collected BGP-LS routes described in , 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.

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 , could also be advertised using BGP-LS .

Traffic Matrix The BGP-EPE controller might collect the traffic matrix to its peers or the final destinations. IP Flow Information Export (IPFIX) 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 .

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.

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 .
• 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}.

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.

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.

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 and
• NETCONF
• Other static or ephemeral APIs

Example: at router A (). Tunnel T1: push {64, 1042} IP route L/8 set next-hop T1

At a Router - Unicast Route Labeled Using BGP (RFC 8277) The BGP-EPE controller could build a unicast route labeled using BGP (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 , 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 "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.

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.

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.

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

IANA Considerations This document has no IANA actions.

Manageability Considerations The BGP-EPE use case described in this document requires BGP-LS extensions that are described in and that consists of additional BGP-LS descriptors and TLVs. Manageability functions of BGP-LS, described in , also apply to the extensions required by the EPE use case. Additional manageability considerations are described in .

Security Considerations defines BGP-LS NLRI instances and their associated security aspects. 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.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network. This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control. Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Individual Cisco Systems Cisco Systems Arrcus, Inc. Individual Contributor Huawei Technologies Informative References The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101. This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol. The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document. This document defines a BGP extension that allows the advertisement of multiple paths for the same address prefix without the new paths implicitly replacing any previous ones. The essence of the extension is that each path is identified by a Path Identifier in addition to the address prefix. This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. This document defines new BGP - Link State (BGP-LS) TLVs in order to carry the IGP Traffic Engineering Metric Extensions defined in the IS-IS and OSPF protocols. Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408.

Acknowledgements The authors would like to thank for his comments and contribution.

Contributors substantially contributed to the content of this document.

Authors' Addresses Cisco Systems, Inc.

Brussels Belgium cfilsfil@cisco.com

Cisco Systems, Inc.

Italy stefano@previdi.net

Cisco Systems, Inc.

United States of America gdawra.ietf@gmail.com

Juniper Networks

1133 Innovation Way Sunnyvale CA 94089 United States of America exa@juniper.net

Yandex

Russian Federation fl0w@yandex-team.ru