]> Cisco Systems, Inc.

cschmutz@cisco.com

Cisco Systems, Inc.

zali@cisco.com

Airtel India

Praveen.Maheshwari@airtel.com

Ciena

rrokui@ciena.com

Nokia

andrew.stone@nokia.com

This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for bandwidth, end-to-end recovery and persistent paths within a SR network. SR Policies satisfying these requirements are called "circuit-style" SR Policies (CS-SR Policies).

Introduction Segment Routing (SR) does allow for a single network to carry both typical IP (connection-less) services and connection-oriented transport services. IP services typically leverage ECMP and TI-LFA. However transport services (commonly referred to as "private lines") are delivered via pseudowires (defined by the PWE3 and PALS workgroups) and require:

• Persistent end-to-end bidirectional traffic engineered paths that provide predictable and identical latency in both directions
• A requested amount of bandwidth per path that is assured irrespective of changing network utilization other services
• Fast end-to-end protection and restoration mechanisms
• Monitoring and maintenance of path integrity
• Data plane remaining up while control plane is down

Such a "transport centric" behavior is referred to as "circuit-style" in this document. This document describes how SR Policies and adjacency-SIDs defined in the SR architecture together with a centralised controller such as a stateful Path Computation Element (PCE) can be used to satisfy those requirements. It includes how end-to-end recovery and path integrity monitoring can be implemented. SR Policies that satisfy those requirements are called "Circuit-Style" SR Policies (CS-SR Policies).

Requirements Notation 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.

Terminology

• BSID : Binding Segment Identifier
• CS-SR : Circuit-Style Segment Routing
• ID : Identifier
• LSP : Label Switched Path
• LSPA : LSP attributes
• NRP : Network Resource Partition
• OAM : Operations, Administration and Maintenance
• OF : Objective Function
• PCE : Path Computation Element
• PCEP : Path Computation Element Communication Protocol
• PT : Protection Type
• SID : Segment Identifier
• SLA : Service Level Agreement
• SR : Segment Routing
• STAMP : Simple Two-Way Active Measurement Protocol
• TI-LFA : Topology Independent Loop Free Alternate
• TLV : Type Length Value

Reference Model The reference model for CS-SR Policies follows the SR architecture and SR Policy architecture and is depicted in .

Circuit-style SR Policy Reference Model | controller |<------------+ | +----------------+ | PCEP/BGP/config PCEP/BGP/config | | v <<<<<<<<<<<<<< CS-SR Policy >>>>>>>>>>>>> v +-------+ +-------+ | |=========================================>| | | A | SR Policy from A to Z | Z | | |<=========================================| | +-------+ SR Policy from Z to A +-------+ ]]>

Given the nature of CS-SR Policies, paths are computed and maintained by a centralized entity providing a consistent simple mechanism for initializing the co-routed bidirectional end-to-end paths, performing bandwidth allocation control, as well as monitoring facilities to ensure SLA compliance for the live of the CS-SR Policy. CS-SR Policies can be instantiated in the endpoints using configuration, PCEP or BGP. When using PCEP as the communication protocol on the endpoints, the centralized entity is a stateful PCE defined in . When using a MPLS data plane , PCEP extensions defined in will be used. When using a SRv6 data plane , , PCEP extensions defined in are used. When using BGP as the communication protocol on the endpoints, the BGP extensions defined in are used. When using configuration, the YANG model defined in does apply. In order to satisfy the requirements of CS-SR Policies, each link in the topology MUST have:

• An adjacency-SID which is:
  • Manually allocated or persistent: to ensure that its value does not change after a node reload
  • Non-protected: to avoid any local TI-LFA protection to happen upon interface/link failures
• The bandwidth available for CS-SR Policies specified
• A per-hop behavior ( or ) that ensures that the specified bandwidth is available to CS-SR Policies at all times independent of any other traffic

In a network with link bundles an adjacency-SID SHOULD be assigned to each member-link (, ) to ensure deterministic traffic placement onto physical links. Similarly, the use of adjacency-SIDs representing parallel adjacencies SHOULD also be avoided. When using a MPLS data plane existing IGP extensions defined in and and BGP-LS defined in can be used to distribute the topology information including those persistent and unprotected adjacency-SIDs. When using a SRv6 data plane , the IGP extensions defined in , and BGP-LS extensions in apply.

Managing Bandwidth In a network, resources are represented by links of certain bandwidth. In a circuit switched network such as SONET/SDH, OTN or DWDM resources (timeslots or a wavelength) are allocated for a provisioned connection at the time of reservation even if no communication is present. In a packet switched network resources are only allocated when communication is present, i.e. packets are to be sent. This allows for the total reservations to exceed the link bandwidth as well in general for link congestion. To satisfy the bandwidth requirement for CS-SR Policies it must be ensured that packets carried by CS-SR Policies can be at all times sent up to the reserved bandwidth on each hop along the path. This is done by:

• Firstly, CS-SR Policy bandwidth reservations per link must be limited to equal or less than the physical link bandwidth.
• Secondly, ensuring traffic for each CS-SR Policy is limited to the bandwidth reserved for that CS-SR Policy by traffic policing or shaping and admission control on the ingress of the pseudowire.
• Thirdly, ensuring that during times of link congestion only non-CS-SR Policy traffic is being buffered or dropped.

For the third step several approaches can be considered:

• Allocate a dedicated physical link of bandwidth P to CS-SR Policies and allow CS-SR reservations up to bandwidth C. Consider bandwidth N allocated for network control, ensure that P - N >= C
• Allocate a dedicate logical link (i.e. 801.q VLAN on ethernet) to CS-SR Policies on a physical link of bandwidth P. Limit the total utilization across all other logical links to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C
• Allocate a dedicated Diffserv codepoint to map traffic of CS-SR Policies into a specific queue not used by any other traffic
• Use of dedicated manual unprotected adjacency-SIDs that are used solely by CS-SR traffic. Features like TI-LFA and microloop avoidance can use dynamic unprotected adjancency-SIDs.

The approach of allocating a Diffserv codepoint can leverage any of the following Per Hop Behavior (PHB) strategies:

• Use a Assured Forwarding (AF) class queue for CS-SR Policies and limit the total utilization across all other queues to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C
• Use a Expedited Forwarding (EF) class queue for CS-SR Policies and limit the total utilization across all other EF queues of higher or equal priority to bandwidth O by traffic policing or shaping and ensure that P - N - O >= C
• Use a Expedited Forwarding (EF) class queue for CS-SR Policies with a priority higher than all other EF queues and limit the utilization of the CS-SR Policy EF queue by traffic policing to C <= P - N

The use of a dedicated Diffserv codepoint for CS-SR traffic requires the marking of all traffic steered into CS-SR Policies on the ingress with that specific codepoint consistently across the domain. In addition, CS-SR Policy telemetry collection can be used to raise alarms when bandwidth utilization thresholds are passed or to request the reserved bandwidth to be adjusted.

CS-SR Policy Characteristics A CS-SR Policy has the following characteristics:

• Requested bandwidth: bandwidth to be reserved for the CS-SR Policy
• Bidirectional co-routed: a CS-SR Policy between A and Z is an association of an SR Policy from A to Z and an SR Policy from Z to A following the same path(s)
• Deterministic and persistent paths: segment lists with strict hops using unprotected adjacency-SIDs
• Not automatically recomputed or reoptimized: the SID list of a candidate path must not change automatically to a SID list representing a different path (for example upon topology change)
• Multiple candidate paths in case of protection/restoration:
  • Following the SR Policy architecture, the highest preference valid path is carrying traffic
  • Depending on the protection/restoration scheme (), lower priority candidate paths
    • may be pre-computed
    • may be pre-programmed
    • may have to be disjoint
• Connectivity verification and performance measurement is activated on each candidate path ()

CS-SR Policy Creation

Policy Creation when using PCEP Considering the scenario illustrated in a CS-SR Policy between A and Z is configured both on A (with Z as endpoint) and Z (with A as endpoint). Both nodes A and Z act as PCC and delegate path computation to the PCE using PCEP with the extensions defined in and the procedure described in . The PCRpt message sent from the headends to the PCE contains the following parameters:

• BANDWIDTH object (Section 7.7 of ) : to indicate the requested bandwidth
• LSPA object (section 7.11 of ) : to indicate that no local protection requirements
  • L flag set to 0 : no local protection
  • E flag set to 1 : protection enforcement (section 5 of )
• ASSOCIATION object () :
  • Type : Double-sided Bidirectional with Reverse LSP Association ()
  • Bidirectional Association Group TLV () :
    • R flag is always set to 0 (forward path)
    • C flag is always set to 1 (co-routed)

If the SR Policies are configured with more than one candidate path, a PCEP request is sent per candidate path. Each PCEP request does include the "SR Policy Association" object (type 6) as defined in to make the PCE aware of the candidate path belonging to the same policy. The signaling extensions described in are used to ensure that

• Path determinism is achieved by the PCE only using segment lists representing a strict hop by hop path using unprotected adjacency-SIDs.
• Path persistency across node reloads in the network is achieved by the PCE only including manually configured adjacency-SIDs in its path computation response.
• Persistency across network changes is achieved by the PCE not performing periodic nor network event triggered re-optimization.

Bandwidth adjustment can be requested after initial creation by signaling both requested and operational bandwidth in the BANDWIDTH object but the PCE is not allowed to respond with a changed path. As discussed in section 3.2 of it may be necessary to use load-balancing across multiple paths to satisfy the bandwidth requirement of a candidate path. In such a case the PCE will notify the PCC to install multiple segment lists using the signaling procedures described in section 5.3 of . In addition to the above described PCC-initiated mode of operation, The SR Policies can be instantiated in the network by a PCE using PCE-initiated procedures.

Policy Creation when using BGP Again considering the scenario illustrated in , there is no CS-SR Policy configuration required on A nor Z to create the CS-SR Policy between A and Z. The centralized controller is instructed (i.e. by an application via an API call) to create the CS-SR Policy, for which the controller does perform path computation and is requesting A via BGP to instantiate a SR Policy (with Z as endpoint) and requesting Z via BGP to instantiate a SR Policy (with Z as endpoint). To instantiate the SR Policies in A and Z the BGP extensions defined in are used. No signaling extensions are required for the following:

• Path determinism is achieved by the controller only using segment lists representing a strict hop by hop path using unprotected adjacency-SIDs.
• Path persistency across node reloads in the network is achieved by the controller only including manually configured adjacency-SIDs in its path computation response.
• Persistency across network changes is achieved by the controller not performing periodic nor network event triggered re-optimization.

If there are more than one candidate paths per SR Policy required, multiple NLRIs with different distinguisher values (see section 2.1 of ) have to be included in the BGP UPDATE message. To achieve load-balancing across multiple paths to satisfy the bandwidth requirement of a candidate path, multiple Segment List Sub-TLVs have to be included in the SR Policy Sub-TLV. See section 2.1 of The endpoints A and Z report the SR Policy states back to the centralized controller via BGP-LS using the extension defined in .

Maximum Segment Depth A Segment Routed path defined by a segment list is constrained by maximum segment depth (MSD), which is the maximum number of segments a router can impose onto a packet. , , and provide the necessary capabilities for a PCE to determine the MSD capability of a router. The MSD constraint is typically resolved by leveraging a label stack reduction technique, such as using Node SIDs and/or BSIDs (SR architecture ) in a segment list, which represents one or many hops in a given path. As described in , adjacency-SIDs without local protection are to be used for CS-SR Policies to ensure no ECMP, no rerouting due to topological changes nor localized protection is being invoked on the traffic, as the alternate path may not be providing the desired SLA. If a CS-SR Policy path requires SID List reduction, a Node SID cannot be utilized as it is eligible for traffic rerouting following IGP re-convergence. However, a BSID can be programmed to a transit node, if the following requirements are met:

• The BSID is unprotected, hence only has one candidate path
• The BSID follows the rerouting and optimization characteristics defined in which implies the SID list of the candidate path MUST only use unprotected adjacency-SIDs.

This ensures that any CS-SR Policies in which the BSID provides transit for do not get rerouted due to topological changes or protected due to failures. A BSID may be pre-programmed in the network or automatically injected in the network by a PCE.

Recovery Schemes Various protection and restoration schemes can be implemented. The terms "protection" and "restoration" are used with the same subtle distinctions outlined in section 1 of , and respectively.

• Protection: another candidate path is computed and fully established in the data plane and ready to carry traffic
• Restoration: a candidate path may be computed and may be partially established but is not ready to carry traffic

The term "failure" is used to represent both "hard failures" such complete loss of connectivity detected by connectivity verification described in or degradation, a packet loss ratio, beyond a configured acceptable threshold.

Unprotected In the most basic scenario, no protection nor restoration is required. The CS-SR Policy has only one candidate path configured. This candidate path is established, activated and is carrying traffic. When using PCEP, a PCRpt message is sent from the PCC to the PCE with the O field in the LSP object set to 2. When using BGP, a BGP-LS update with a SR Policy Candidate Path NLRI is sent from the endpoint to the centralized controller having

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• A flag set to 1 to indicate the candidate path is active and carrying traffic

In case of a failure along the path the CS-SR Policy will go down and traffic will not be recovered. Typically, two CS-SR Policies are deployed either within the same network with disjoint paths or in two separate networks and the overlay service is responsible for traffic recovery.

1:1 Protection For fast recovery against failures the CS-SR Policy has two candidate paths. Both paths are established but only the candidate with higher preference is activated and is carrying traffic. The second candidate path is programmed as backup in the forwarding plane as described in . When using PCEP, the PCRpt message for the candidate path with higher preference will have the O field in the LSP object set to 2. For the candidate path with the lower preference the O field in the LSP object is set to 1. Appropriate routing of the protect path diverse from the working path can be requested from the PCE by using the "Disjointness Association" object (type 2) defined in in the PCRpt messages. The disjoint requirements are communicated in the "DISJOINTNESS-CONFIGURATION TLV"

• L bit set to 1 for link diversity
• N bit set to 1 for node diversity
• S bit set to 1 for SRLG diversity
• T bit set to enforce strict diversity

The P bit may be set for first candidate path to allow for finding the best working path that does satisfy all constraints without considering diversity to the protect path. The "Objective Function (OF) TLV" as defined in section 5.3 of may also be added to minimize the common shared resources. When using BGP, the controller is already aware of the disjoint requirements and does consider them while computing both paths. Two NLRIs with different distinguisher values and different preference values are included in the BGP UPDATE sent to the headend routers. A BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the candidate path with higher preference with

• C flag set to 1 to indicate that candidate path was provisioned by the controller
• A flag set to 1 to indicate the candidate path is active and carrying traffic

and another SR Policy Candidate Path NLRI for the candidate path with lower preference with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• B flag set to 1 to indicate the role of backup path

Upon a failure impacting the candidate path with higher preference carrying traffic, the candidate path with lower preference is activated immediately and traffic is now sent across it. When using PCEP a PCRpt message for the higher preference candidate path is sent to the PCE with the O field changed from 2 to 0 and a PCRpt message for the lower preference candidate path with the O field change from 1 to 2. When using BGP a BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the candidate path with higher preference with the A flag cleared and for another BGP-LS update for the candidate path with lower preference with the B flag cleared and A flag set to 1. Protection switching is bidirectional. As described in , both headends will generate and receive their own loopback mode test packets, hence even a unidirectional failure will always be detected by both headends without protection switch coordination required.

Reversion Two cases are to be considered when the failure(s) impacting a candidate path with higher preference are cleared:

• Revertive switching: re-activate the higher preference candidate path and start sending traffic over it
• Non-revertive switching: do not activate the higher preference candidate path and keep sending traffic via the lower preference candidate path

When using PCEP, for revertive switching a PCRpt message for the recovered higher preference candidate path is sent to the PCE with the O field changed from 0 to 2 and send a PCRpt message for the lower preference candidate path with the O field changed from 2 to 1. For non-revertive switching only a PCRpt message for the recovered higher preference candidate path with the O field set to 1 is sent. When using BGP and revertive switching a BGP-LS update is sent to the controller with a SR Policy Candidate Path NLRI for the recovered higher preference candidate path with the A flag set to 1 and another BGP-LS update for the lower preference candidate path with the A flag cleared and B flag set to 1. For non-revertive switching only a BGP-LS update for the higher preference candidate path with the B flag set to 1 is sent.

Restoration

1+R Restoration Compared to 1:1 protection described in , this restoration scheme avoids pre-allocating protection bandwidth in steady state, while still being able to recover traffic flow in case of a network failure in a deterministic way (maintain required bandwidth commitment) When using PCEP, the CS-SR Policy is configured with two candidate paths. The candidate path with higher preference is established, activated (O field in LSP object is set to 2) and is carrying traffic. The second candidate path with lower preference is only established and activated (PCRpt message to the PCE with O field in LSP object is set to 2) upon a failure impacting the first candidate path in order to send traffic over an alternate path through the network around the failure with potentially relaxed constraints but still satisfying the bandwidth commitment. The second candidate path is generally only requested from the PCE and activated after a failure, but may also be requested and pre-established during CS-SR Policy creation with the downside of bandwidth being set aside ahead of time. As soon as failure(s) that brought the first candidate path down are cleared, the second candidate path is getting deactivated (PCRpt message to the PCE with O field in LSP object is set to 1) or torn down. The first candidate path is activated (PCRpt message to the PCE with O field in LSP object is set to 2) and traffic sent across it. When using BGP, the controller does compute one path and does include one NLRI in the BGP UPDATE message sent to the headend routers to instantiate the CS-SR Policy with one candidate path active and carrying traffic. A BGP-LS update with a SR Policy Candidate Path NLRI is sent to the controller with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• A flag set to 1 to indicate the candidate path is active and carrying traffic

Upon the controller detecting the failure of the CS-SR Policy's candidate path, another path is computed and added as second candidate path to the CS-SR Policy by sending a BGP UPDATE message to the headend routers with a NLRI distinguisher value being different and preference being lower compared to the first candidate path. A BGP-LS update with a SR Policy Candidate Path NLRI for the candidate path with higher preference is sent to the controller with

• A flag is cleared to indicate the candidate path is no longer active and not carrying traffic anymore

and another SR Policy Candidate Path NLRI for the candidate path with lower preference with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• A flag set to 1 to indicate the candidate path is active and carrying traffic

The second candidate path is generally only instantiated by the controller and activated after a failure, but may also be instantiated and pre-established during CS-SR Policy creation with the downside of bandwidth being set aside ahead of time. If so, a BGP-LS update with a SR Policy Candidate Path NLRI is sent to the controller with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• B flag set to 1 to indicate the role of backup path

Once the controller has detected the failure(s) that brought the first candidate path down are cleared, a BGP-LS update with a SR Policy Candidate Path NLRI for the first candidate path is sent to the controller with

• A flag set to 1 to indicate the candidate path became active and is carrying traffic again

The second candidate path is getting removed by a BGP UPDATE message withdrawing the NLRI of the second candidate path. Restoration and reversion behavior is bidirectional. As described in , both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.

1:1+R Restoration For further resiliency in case of multiple concurrent failures that could affect both candidate paths of 1:1 protection described in , a third candidate path with a preference lower than the other two candidate paths is added to the CS-SR Policy to enable restoration. When using PCEP, the third candidate path will generally only be established, activated (PCRpt message to the PCE with O field in LSP object is set to 2) and carry traffic after failure(s) have impacted both the candidate path with highest and second highest preference. The third candidate path may also be requested and pre-computed already whenever either the first or second candidate path went down due to a failure with the downside of bandwidth being set aside ahead of time. As soon as failure(s) that brought either the first or second candidate path down are cleared, the affected candidate path is activated again (PCRpt message to the PCE with O field in LSP object is set to 2). The third candidate path is to be deactivated (PCRpt message to the PCE with O field in LSP object is set to 1). When using BGP, the third candidate path will generally only be instantiated by the controller and activated after failure(s) have impacted both the candidate path with highest and second highest preference, but may also be instantiated and pre-established during CS-SR Policy creation with the downside of bandwidth being set aside ahead of time. Assuming the case where both candidate paths are down, a BGP-LS update is sent with SR Policy Candidate Path NLRIs for the first and second candidate path with

• A flag cleared

and a SR Policy Candidate Path NLRI for the third candidate path with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• A flag set to 1 to indicate the candidate path is active and carrying traffic

Assuming the case where only one candidate path is down, a BGP-LS update is sent with a SR Policy Candidate Path NLRI for the failed candidate path with

• A flag cleared

a SR Policy Candidate Path NLRI for the second candidate path with

• A flag set to 1 to indicate it is active and carrying traffic network

and another SR Policy Candidate Path NLRI for the newly installed third candidate path with

• C flag set to 1 to indicate the candidate path was provisioned by the controller
• B flag set to 1 to indicate the role of backup path

Once the controller has detected the failure(s) that brought either the first or the second candidate path down are cleared, a BGP-LS update with a SR Policy Candidate Path NLRI for the affected candidate path is sent to the controller with

• A flag set to 1 to indicate the candidate path became active again

The third candidate path is getting removed by a BGP UPDATE message withdrawing the NLRI of the third candidate path. Again, restoration and reversion behavior is bidirectional. As described in , both headends use connectivity verification in loopback mode and therefore even in case of unidirectional failures both headends will detect the failure or clearance of the failure and switch traffic away from the failed or to the recovered candidate path.

Operations, Administration, and Maintenance (OAM)

Connectivity Verification The proper operation of each segment list is validated by both headends using STAMP in loopback measurement mode as described in section 4.2.3 of . As the STAMP test packets are including both the segment list of the forward and reverse path, standard segment routing data plane operations will make those packets get switched along the forward path to the tailend and along the reverse path back to the headend. When using PCEP, the headend forms the bidirectional SR Policy association using the procedure described in and receives the information about the reverse segment list from the PCE as described in section 4.5 of When using BGP, the controller does inform the headend routers about the reverse segment list using the Reverse Segment List Sub-TLV defined in section 4.1 of . For cases where multiple segment lists are used by a candidate path, the headends will declare a candidate path down after connectivity verification has failed for one or more segment lists because the bandwidth requirement of the candidate path can no longer be met.

Performance Measurement The same STAMP session is used to estimate round-trip loss as described in section 5 of . The same STAMP session used for connectivity verification can be used to measure delay. As loopback mode is used only round-trip delay is measured and one-way has to be derived by dividing the round-trip delay by two.

Candidate Path Validity Verification A stateful PCE/controller is in sync with the network topology and the CS-SR Policies provisioned on the headend routers. As described in a path must not be automatically recomputed after or optimized for topology changes. However, there may be a requirement for the stateful PCE/controller to tear down a path if the path no longer satisfies the original requirements, detected by stateful PCE/controller, such as insufficient bandwidth, diversity constraint no longer met or latency constraint exceeded. The headend may measure the actual bandwidth utilization of a CS-SR Policy to take local action and/or report it as requested bandwidth via PCEP or BGP-LS to the stateful PCE/controller. Typical actions are raising alarms or adjusting the reserved bandwidth. For a CS-SR Policy configured with multiple candidate paths, a headend may switch to another candidate path if the stateful PCE/controller decided to tear down the active candidate path.

External Commands

Candidate Path Switchover It is very common to allow operators to trigger a switch between candidate paths even if no failure is present. I.e. to proactively drain a resource for maintenance purposes. Operator triggered switching between candidate paths is unidirectional and has to be requested on both headends.

Candidate Path Re-computation While no automatic re-optimization or pre-computation of CS-SR Policy candidate paths is allowed as specified in , network operators trying to optimize network utilization may explicitly request a candidate path to be re-computed at a certain point in time.

Security Considerations This document does not define any new protocol extensions and therefore does not introduce any new security considerations. does outline considerations for SR Policies including SR-MPLS and SRv6. When using PCEP, the considerations in and to apply. Section 7 of does define security consideration for SR Policy instantiation via BGP. When instantiating the Policies via configuration, requirements defined the Section 8 of do apply.

IANA Considerations This document has no IANA actions.

Acknowledgements The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh Gandhi, Alexander Vainshtein and Tarek Saad for providing their review comments and all contributors for their inputs and support.

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. 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. Informative References 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. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. 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. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). 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. Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH). This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP. Huawei Technologies Cisco Systems Cisco Systems Microsoft Google A Segment Routing (SR) Policy is an ordered list of segments (also referred to as instructions) that define a source-routed policy. An SR Policy consists of one or more candidate paths, each comprising one or more segment lists. A headend can be provisioned with these candidate paths using various mechanisms, such as CLI, NETCONF, PCEP, or BGP. This document specifies how BGP can be used to distribute SR Policy candidate paths. It introduces a BGP SAFI for advertising a candidate path of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these candidate paths. Furthermore, this document updates RFC9012 by extending the Color Extended Community to support additional steering modes over SR Policy. Cisco Systems Cisco Systems Huawei Technologies Bell Canada Equinix SoftBank Juniper Networks This document defines a YANG data model for Segment Routing (SR) Policy that can be used for configuring, instantiating, and managing SR policies. The model is generic and applies equally to the MPLS and SRv6 instantiations of SR policies. This document defines a PHB (per-hop behavior) called Expedited Forwarding (EF). The PHB is a basic building block in the Differentiated Services architecture. EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate. This document obsoletes RFC 2598. [STANDARDS-TRACK] This document defines a general use Differentiated Services (DS) Per-Hop-Behavior (PHB) Group called Assured Forwarding (AF). [STANDARDS-TRACK] There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links that comprise the Layer 2 interface bundle, link attribute information about the bundle members is required. This document introduces the ability for IS-IS to advertise the link attributes of Layer 2 (L2) Bundle Members. There are deployments where the Layer 3 (L3) interface on which OSPF operates is a Layer 2 (L2) interface bundle. Existing OSPF advertisements only support advertising link attributes of the L3 interface. If entities external to OSPF wish to control traffic flows on the individual physical links that comprise the L2 interface bundle, link attribute information for the bundle members is required. This document defines the protocol extensions for OSPF to advertise the link attributes of L2 bundle members. The document also specifies the advertisement of these OSPF extensions via the Border Gateway Protocol - Link State (BGP-LS) and thereby updates RFC 9085. Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane. Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological subpaths called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the OSPFv2 extensions required for Segment Routing. Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies. This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. Segment Routing over IPv6 (SRv6) allows for a flexible definition of end-to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths called "segments". These segments are advertised by various protocols such as BGP, IS-IS, and OSPFv3. This document defines extensions to BGP - Link State (BGP-LS) to advertise SRv6 segments along with their behaviors and other attributes via BGP. The BGP-LS address-family solution for SRv6 described in this document is similar to BGP-LS for SR for the MPLS data plane, which is defined in RFC 9085. Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. Cisco Systems Cisco Systems Cisco Systems Orange INSA Lyon Cisco Systems This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination. This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] This document updates RFC 5440 to clarify usage of the Local Protection Desired bit signaled in the Path Computation Element Communication Protocol (PCEP). This document also introduces a new flag for signaling protection enforcement in PCEP. This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE. Huawei Technologies Huawei Technologies China Mobile Cisco Systems, Inc. ZTE Corporation The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. Segment routing (SR) leverages the source routing and tunneling paradigms. The Stateful PCEP extensions allow stateful control of Segment Routing Traffic Engineering (TE) Paths. Furthermore, PCEP can be used for computing SR TE paths in the network. This document defines PCEP extensions for grouping two unidirectional SR Paths (one in each direction in the network) into a single associated bidirectional SR Path. The mechanisms defined in this document can also be applied using a stateful PCE for both PCE- initiated and PCC-initiated LSPs or when using a stateless PCE. This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling. Ciena Corporation Ciena Corporation Cisco Systems, Inc. Juniper Networks, Inc. Huawei Technologies Nokia Segment Routing (SR) allows a node to steer a packet flow along any path. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. An SR Policy is made of one or more candidate paths. This document specifies the Path Computation Element Communication Protocol (PCEP) extension to signal candidate paths of the SR Policy. Additionally, this document updates RFC 8231 to allow stateful bring up of an SR Label Switched Path (LSP), without using the path computation request and reply messages. This document is applicable to both Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6). Cisco Systems, Inc. Airtel India Nokia Verizon Huawei Technologies Segment Routing (SR) enables a node to steer packet flows along a specified path without the need for intermediate per-path states, due to the utilization of source routing. An SR Policy comprises a sequence of segments, which are essentially instructions that define a source-routed policy This document proposes a set of extensions to the Path Computation Element Communication Protocol (PCEP) for Segment Routing Policies that are designed to satisfy requirements for connection-oriented transport services (Circuit-Style SR policies). They include the ability to control path recomputation and the option to request path with strict hops only and are also applicable for generic SR policy use cases where controlling path recomputation or distinct hop requirements are applicable. Ciena Corporation Ciena Corporation Juniper Networks, Inc. Juniper Networks, Inc. Nokia Ciena Huawei Technologies Verizon Inc. Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths, that together form a solution. Returning just one single traffic path does not provide a valid solution. This document defines mechanisms to encode multiple paths for a single set of objectives and constraints. This allows encoding of multiple Segment Lists per Candidate Path within a Segment Routing Policy. The new PCEP mechanisms are meant to be generic, where possible, to allow for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Individual Cisco Systems Huawei Technologies RtBrick Inc. Nvidia This document describes a mechanism to collect the Segment Routing Policy information that is locally available in a node and advertise it into BGP Link-State (BGP-LS) updates. Such information can be used by external components for path computation, re-optimization, service placement, network visualization, etc. This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled. This document defines a way for an Open Shortest Path First (OSPF) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document only refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3. This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. This document describes protocol-specific procedures and extensions for Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to support end-to-end Label Switched Path (LSP) recovery that denotes protection and restoration. A generic functional description of GMPLS recovery can be found in a companion document, RFC 4426. [STANDARDS-TRACK] This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. This document introduces a simple mechanism to associate a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element Communication Protocol (PCEP) with the purpose of computing diverse (disjointed) paths for those LSPs. The proposed extension allows a Path Computation Client (PCC) to advertise to a Path Computation Element (PCE) that a particular LSP belongs to a particular Disjoint Association Group; thus, the PCE knows that the LSPs in the same group need to be disjoint from each other. Cisco Systems, Inc. Cisco Systems, Inc. Bell Canada Huawei Nokia Segment Routing (SR) leverages the source routing paradigm and applies to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes procedures for Performance Measurement in SR networks using Simple Two-Way Active Measurement Protocol (STAMP) defined in RFC 8762, along with its optional extensions defined in RFC 8972 and further augmented in RFC 9503. The described procedure is used for links and SR paths (including SR Policies and SR IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services in SR networks, and is applicable to both SR-MPLS and SRv6 data planes. Huawei Technologies Huawei Technologies China Telecom China Mobile Cisco Systems A Segment Routing(SR) policy identifies a set of candidate SR paths Each SR path is passed in BGP as the SR Policy SAFI NLRI accompanied with the Tunnel Encapsulation attribute (Tunnel-encaps). Each SR Path (tunnel) uses a set of TLVs in the Tunnel-encaps attribute to describe the characteristics of the SR Policy tunnel. One of the TLVs that describes the tunnel is the Segment list TLV which provides a list of segments contained in the tunnel. This document specifies a new Path Segment Sub-TLV to associate a Path Segment ID to the SR Segment List. The Path Segment ID can be used for performance measurement, path correlation, and end-2-end path protection. This Path Segment identifier can be also be used to correlate two unidirectional SR paths into a bidirectional SR path. Bidirection SR path may be required in some scenarios such as mobile backhaul transport network.

Contributors Bell Canada

daniel.voyer@bell.ca

Verizon

luay.jalil@verizon.com

Huawei Technologies

pengshuping@huawei.com

Cisco Systems, Inc.

cfilsfil@cisco.com

Cisco Systems, Inc.

fclad@cisco.com

Cisco Systems, Inc.

tsaad.net@gmail.com

Cisco Systems, Inc.

brfoster@cisco.com

Cisco Systems, Inc.

bduvivie@cisco.com

Cisco Systems, Inc.

slitkows@cisco.com

Huawei Technologies

jie.dong@huawei.com