]> 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. The association of two co-routed unidirectional SR Policies satisfying these requirements is called "Circuit Style" SR Policy (CS-SR Policy).

Introduction IP services typically leverage ECMP and local protection. However, packet transport services (commonly referred to as "private lines") that are delivered via pseudowires such as , , , and for example, require:

• Persistent end-to-end bidirectional traffic engineered paths that provide predictable and near-symmetric latency
• A requested amount of bandwidth per path that is assured irrespective of changing network utilization from 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 Segment Routing (SR) Policies and adjacency segment identifiers (adjacency-SIDs) defined in the SR architecture together with a centralized 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. A Circuit Style SR Policy (CS-SR Policy) is an association of two co-routed unidirectional SR Policies satisfying the above requirements and allowing for a single SR network to carry both typical IP (connection-less) services and connection-oriented transport services.

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
• DWDM : Dense Wavelength Division Multiplexing
• 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
• SDH : Synchronous Digital Hierarchy
• SONET : Synchronous Optical Network
• 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 life of the CS-SR Policy. CS-SR Policies can be instantiated in the headend routers by using PCEP or BGP as a communication protocol between the headend routers and the central controller or by configuration.

• When using PCEP as the communication protocol, the controller is a stateful PCE as defined in . When using SR-MPLS , PCEP extensions defined in are used. When using SRv6 , PCEP extensions defined in are used.
• When using BGP as the communication protocol, the BGP extensions defined in are used.
• When using configuration, an appropriate YANG model such as can be used.

To satisfy the requirements of CS-SR Policies, each link in the topology used by or intended to support CS-SR Policies MUST have:

• An adjacency-SID which is:
  • Persistent, which could be statically configured or auto-generated: to ensure that its value does not change after an event that may cause dynamic states to change (e.g. router reboot).
  • 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 always available to CS-SR Policies independent of any other traffic.

When using link bundles (i.e. ), parallel physical links are only represented via a single adjacency. To ensure deterministic traffic placement onto physical links and Operations, Administration, and Maintenance (OAM) per physical link, an adjacency-SID SHOULD be assigned to each physical link (aka member-link) (, ). This is not needed when the traffic carried by a CS-SR Policy has enough entropy (, , ) for traffic load-balancing across multiple member-links to work well. Similarly, the use of adjacency-SIDs representing parallel adjacencies SHOULD also be avoided. When using SR-MPLS , 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 SRv6 , the IGP extensions defined in and 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 Synchronous Optical Network (SONET) / Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN) or Dense Wave Division Multiplexing (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 and can in general lead to link congestion and packet loss. To satisfy the bandwidth requirement for CS-SR Policies it must be ensured that packets carried by CS-SR Policies can always be 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 persistent unprotected adjacency-SIDs that are solely used by CS-SR traffic, managed by network design and policy (which is outside the scope of this document). These dedicated SIDs used by CS-SR Policies MUST NOT be used by features such as TI-LFA for defining the repair path and microloop avoidance for defining the loop-free path.

The approach of allocating a Diffserv codepoint can leverage any of the following Per-Hop Behavior (PHB) strategies below, where P is the bandwidth of a physical link, N is the bandwidth allocated for network control and C is the bandwidth reserved for CS-SR policies:

• 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, the headends MAY measure the actual bandwidth utilization of a CS-SR Policy to raise alarms when bandwidth utilization thresholds are passed or to request the reserved bandwidth to be adjusted. Using telemetry collection the alarms or bandwidth adjustments can also be triggered by the controller.

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

• Requested bandwidth: bandwidth to be reserved for the CS-SR Policy
  • Bandwidth may be adjusted after initial creation as long as no change in path is required
  • Multiple segment-lists may be instantiated to satisfy the bandwidth requirement
• Bidirectional co-routed: a CS-SR Policy between headends 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 that can be statically configured or auto-generated.
• Not automatically recomputed or reoptimized: the segment list of a candidate path MUST NOT change automatically to a segment list representing a different path (for example upon topology change).
• More than one 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.
  • Protection switching, restoration and reversion behavior is bidirectional
• It is RECOMMENDED that candidate paths only contain one segment list to avoid asymmetrical routing due to independent load balancing across multiple segment lists on each headend.
• Continuity check and performance measurement are activated on each candidate path () and performed per segment-list.

CS-SR Policy Creation

Policy Creation when using PCEP

PCC-initiated Mode Considering the scenario illustrated in a CS-SR Policy between headends A and Z is instantiated by configured a SR Policy on both headend A (with Z as endpoint) and headend Z (with A as endpoint). Both headend routers A and Z act as PCC and delegate path computation to the PCE using PCEP with the procedures described in . For SR-MPLS the extensions defined in are used. And SRv6 specific extensions are defined in . The functional requirements of an CS-SR Policy expressed in are signaled using PCEP extensions defined in , , , , and . The candidate paths of the CS-SR Policy are reported and updated following PCEP procedures of .

PCE-initiated Mode The CS-SR Policy can be instantiated in the network between headends A and Z by a PCE using PCE-initiated procedures defined in . For PCE-initiated procedures no SR Policy configuration is required on the headends A and Z acting as PCC. The PCE performs path computation in line with the functional requirements expressed in and requests the headends A and Z to initiate a SR Policy using the PCEP extensions listed in . Following initiation, the candidate paths of the CS-SR Policy are reported and updated following PCEP procedures of and share the same behavior as the PCC-initiated mode. Connectivity verification and performance measurement is enabled via local policy configuration on the headends, as there is no standard signaling mechanism available.

Policy Creation when using BGP Considering the scenario illustrated in , instead of configuring SR Policies on both headend A (with Z as endpoint) and headend Z (with A as endpoint), a CS-SR Policy between A and Z is instantiated by a request (e.g. application API call) to the controller. The controller performs path computation in line with the functional requirements expressed in and instantiates the SR Policies in headends A and Z using the BGP extensions defined in . Connectivity verification and performance measurement is enabled via local policy configuration on the headends, as there is no standard signaling mechanism available.

Maximum SID Depth Constraint The segment lists used by CS-SR Policy candidate paths are constrained by the maximum number of segments a router can impose onto a packet. When using SR-MPLS this constraint is called "Base MPLS Imposition MSD" and is advertised via IS-IS , OSPF , BGP-LS and PCEP . When using SRv6 this constraint is called "SRH Max H.encaps MSD" and is advertised via IS-IS , OSPF , BGP-LS and PCEP . The MSD constraint is typically resolved by leveraging a segment list reduction technique, such as using Node SIDs and/or Binding SIDs (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 used in CS-SR Policies to ensure that there is no per-hop ECMP, no localized rerouting due to topological changes, and no invocation of localized protection mechanisms, as the alternate path may not be providing the desired SLA. If a CS-SR Policy path requires segment list reduction, a SR Policy can be programmed in a transit node, and its BSID can be used in the segment list of the CS-SR Policy, if the following requirements are met:

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

This ensures that traffic for CS-SR Policies using a BSID does not get locally rerouted due to topological changes or locally protected due to failures. A transit SR Policy may be pre-programmed in the network or automatically injected in the network by a PCE.

CS-SR Policy State Reporting CS-SR Policy state reporting by the headend routers back to the central controller is essential to confirm success or failure of the instantiation and making the controller aware of any state changes throughout the lifetime of the CS-SR Policy in the network. The headend routers can report CS-SR Policy state by using

• PCEP procedures of .
• BGP-LS procedures of .
• an appropriate YANG model such as .

CS-SR Policy Deletion

Policy Deletion when using PCEP When using PCC-initiated mode, the headends A and Z send a PCRpt message with the R flag set to 1 to inform the PCE about the deletion of a candidate path. When using PCE-initiated mode, the PCE does send a PCInitiate message to the headends A and Z and to instruct them to delete a candidate path.

Policy Deletion when using BGP The controller is using the withdraw procedures of to instruct headends A and Z to delete a candidate path.

Recovery Schemes Various recovery (protection and restoration) schemes can be implemented for a CS-SR Policy. As described in , there is a subtle distinction between the terms "protection" and "restoration" based on the resource allocation done during the recovery path establishment. The same definitions apply for CS-SR Policy recovery schemes, wherein:

• 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 continuity check described in or degradation, i.e., when the packet loss ratio increased beyond a configured acceptable threshold. For candidate path establishment the procedures described in , for candidate path tear down the procedures in and for state reporting the procedures in can be used.

Unprotected In the most basic scenario, no protection or restoration is required. The CS-SR Policy has only one candidate path. 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. As soon as the failure(s) that brought the candidate path down are cleared, the candidate path is activated, traffic is sent across it and state is reported accordingly.

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 MUST be computed disjoint to the first candidate path and programmed as backup in the forwarding plane as described in . 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. 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. Two cases are to be considered when the failure condition impacting a candidate path with higher preference has 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.

Restoration

1+R Restoration Similarly to 1:1 protection described in , in this recovery scheme the CS-SR Policy has two candidate paths. To avoid pre-allocating protection bandwidth by the controller ahead of failures, but still being able to recover traffic flow over an alternate path through the network in a deterministic way (maintaining the required bandwidth commitment), the second candidate path with lower preference is established "on demand" and activated upon failure of the first candidate path. As soon as failure(s) that brought the first candidate path down are cleared, the second candidate path is getting torn down and traffic is reverted to the first candidate path. Restoration and reversion behavior is bidirectional. As described in , both headends use continuity check 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 bring down both candidate paths of 1:1 protection described in , a third candidate path with a preference lower than the other two candidate paths (in this section referred to as first and second candidate path) is added to the CS-SR Policy to enable restoration. There are two possible operating models:

• R established upon double failure

• As in , to avoid pre-allocating additional bandwidth by the controller ahead of failures, the third candidate path may only be requested when both candidate paths are affected by failures.

• As soon as either the first or second candidate path recovers, traffic will be reverted and the third candidate path MUST be torn down.

• R pre-established after single failure

• Alternatively, the third candidate path can also be requested, pre-computed and programmed as backup already whenever either the first or second candidate path go down with the downside of more bandwidth being set aside ahead of time. When doing so, the third candidate path MUST be computed disjoint to the still operational candidate path.

• The third candidate path will get activated and carry traffic when further failures lead to both the first and second candidate path being down.

• As long as either the first or the second candidate path is active, the third candidate path is kept, updated (if needed) to ensure diversity to the active candidate path and is not carrying traffic.

• Once both, the first and the second candidate path have recovered, the third candidate path is torn down.

Again, restoration and reversion behavior is bidirectional. As described in , both headends use continuity check 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)

Continuity Check The continuity check for each segment list on both headends MAY be done using

• Simple Two-Way Active Measurement Protocol (STAMP) in loopback measurement mode as described in section 6 and the session state described in section 11 of for SR-MPLS and for SRv6.
• Bidirectional Forwarding Detection (BFD) .
• Seamless BFD (S-BFD) .

The use of STAMP is RECOMMENDED as it leverages a single protocol for both continuity check and performance measurement (see of this document) and allows for a single session to be used, depending on the desired performance measurement session mode (two-way described in section 4, one-way described in section 5 or loopback described in section 6 of for SR-MPLS and for SRv6). 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 forwarded along the forward path to the tailend and along the reverse path back to the headend. To be able to send STAMP test packets for loopback measurement mode, the STAMP Session-Sender (i.e., the headend) needs to acquire the segment list information of the reverse path:

• 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 continuity check has failed for one or more segment lists because the bandwidth requirement of the candidate path can no longer be met.

Performance Measurement Assuming a single STAMP session in loopback mode is used for continuity check and performance measurement, the round-trip delay can be measured and the round-trip loss can be estimated as described in section 8 of for SR-MPLS and for SRv6. Considering that candidate paths are co-routed, the delay in the forward and reverse direction can be assumed to be similar. Under this assumption, one-way delay can be derived by dividing the round-trip delay by two.

Candidate Path Validity Verification A stateful PCE/controller is in sync with the headend routers in the network topology and the CS-SR Policies provisioned on them. As described in a path MUST NOT be automatically recomputed by the controller after or optimized for topology changes unless it is a restoration path. 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, such as insufficient bandwidth, diversity constraint no longer met or latency constraint exceeded and only the stateful PCE/controller can detect this and not the headend routers themselves. 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.

Operational Considerations As a Circuit Style SR Policy (CS-SR Policy) is an association of two co-routed unidirectional SR Policies, the manageability considerations outlined in do apply. Additional operational considerations are:

• Configure both sides identical (behavior and flags)
• When using PCEP, configure Association ID, Association Source, optional Global Association Source TLV, and optional Extended Association ID TLV according to .
• LSP ping and traceroute [] is performed unidirectionally (per SR Policy).
• Diversity among candidate paths can be verified by using LSP traceroute.
• CS-SR Policies will lead to more alarms in the fault management system, because a candidate path can stay down until a network topology failure which caused the down event clears.

Configuration and operation can use the YANG model defined in .

External Commands External commands are typically issued by an operator to control the candidate path state of a CS-SR Policy using the management interface of:

• Headends: When the CS-SR Policy was instantiated via configuration or PCEP PCC-initiated mode
• PCE/controller: When the CS-SR Policy was instantiated via BGP or PCEP PCE-initiated mode

Candidate Path Switchover It is very common to allow operators to trigger a switch between candidate paths even if no failure is present, e.g., to proactively drain a resource for maintenance purposes. A operator triggered switching request between candidate paths on a headend is unidirectional and SHOULD be requested on both headends to ensure co-routing of traffic.

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 provide guidance on how to implement a CS-SR Policy leveraging existing mechanisms and protocol extensions. As such, it does not introduce any new security considerations. The MPLS or SRv6 network is assumed to be a trusted and secure domain. Attackers who manage to send spoofed packets into the domain could easily disrupt services leveraging CS-SR Policies. The protections against such attacks are described by considerations in and in . Security considerations for the SR Policy Architecture defined in do apply to this document as well. To satisfy the bandwidth requirement of CS-SR Policies, the Differentiated Service architecture is leveraged and the security considerations in do apply. If a dedicated Diffserv codepoint is assigned to CS-SR Policies, the use by any other traffic is to be prevented to ensure QoS is properly enforced. Further a misconfiguration of requested bandwidth for CS-SR Policies can lead to blocking out other CS-SR Policies from consuming available bandwidth and bandwidth starvation of non-CS-SR traffic. Depending on how a CS-SR Policy is instantiated and reported, the following security considerations do apply

• PCEP:
  • Section 8 of
  • Section 6 of
  • Section 7 of
  • Section 10 of
  • Section 8 of
• BGP:
  • Section 7 of
  • Section 9 of
• Configuration:
  • Section 8 of

Depending on the protocol used for OAM, the following security considerations do apply

• STAMP: Section 15 of and
• BFD/S-BFD: Section 9 of and Section 11 of

IANA Considerations This document has no IANA actions.

Acknowledgements The author's want to thank Samuel Sidor, Mike Koldychev, Rakesh Gandhi, Alexander Vainshtein, Tarek Saad, Ketan Talaulikar and Yao Liu for providing their review comments, Yao Liu for her very detailed shepherd review and all contributors for their inputs and support.

References Normative 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) 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. This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as inter-AS and inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community. 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. 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. 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. 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. 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 (CPs), each comprising one or more segment lists. A headend can be provisioned with these CPs using various mechanisms such as Command-Line Interface (CLI), Network Configuration Protocol (NETCONF), Path Computation Element Communication Protocol (PCEP), or BGP. This document specifies how BGP can be used to distribute SR Policy CPs. It introduces a BGP SAFI for advertising a CP of an SR Policy and defines sub-TLVs for the Tunnel Encapsulation Attribute to signal information related to these CPs. Furthermore, this document updates RFC 9012 by extending the Color Extended Community to support additional steering modes over SR Policy. Cisco Systems Cisco Systems Huawei Technologies 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. Where the payload of a pseudowire comprises a number of distinct flows, it can be desirable to carry those flows over the Equal Cost Multiple Paths (ECMPs) that exist in the packet switched network. Most forwarding engines are able to generate a hash of the MPLS label stack and use this mechanism to balance MPLS flows over ECMPs. This document describes a method of identifying the flows, or flow groups, within pseudowires such that Label Switching Routers can balance flows at a finer granularity than individual pseudowires. The mechanism uses an additional label in the MPLS label stack. [STANDARDS-TRACK] Load balancing is a powerful tool for engineering traffic across a network. This memo suggests ways of improving load balancing across MPLS networks using the concept of "entropy labels". It defines the concept, describes why entropy labels are useful, enumerates properties of entropy labels that allow maximal benefit, and shows how they can be signaled and used for various applications. This document updates RFCs 3031, 3107, 3209, and 5036. [STANDARDS-TRACK] This document specifies the IPv6 Flow Label field and the minimum requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding labeled packets, and flow state establishment methods. Even when mentioned as examples of possible uses of the flow labeling, more detailed requirements for specific use cases are out of the scope for this document. The usage of the Flow Label field enables efficient IPv6 flow classification based only on IPv6 main header fields in fixed positions. [STANDARDS-TRACK] 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 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. 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) can be used to steer packets through a network employing the source routing paradigm. SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. Stateful PCEP extensions for SR allow a PCE to maintain state and to control and initiate SR Traffic Engineering (TE) LSPs. PCEP supports grouping of two unidirectional MPLS-TE Label Switched Paths (LSPs), signaled via RSVP-TE, using association. This document defines PCEP extensions for grouping two unidirectional SR LSPs (one in each direction in the network) into a single associated bidirectional SR LSP. The mechanisms defined in this document are applicable to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs. A Segment Routing (SR) Policy is an ordered list of instructions called "segments" that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated. 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 an SR Policy. Additionally, this document updates RFC 8231 to allow delegation and setup 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 can consist of one or a set of candidate paths, where each candidate path is represented by a segment list or a set of segment lists, which are essentially instructions that define a source-routed path. This document specifies 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 modification and the option to request a strict hop-by-hop path, being also applicable for generic SR policy use cases where controlling path modification or deterministic and persistent path requirements are applicable. Ciena Corporation Ciena Corporation Cisco Systems Juniper Networks, Inc. Nokia Huawei Technologies Cisco Systems. Certain traffic engineering path computation problems require solutions that consist of multiple traffic paths that together form a solution. However, current PCEP extensions can only return a single traffic path, which cannot meet the requirements. 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 Path Computation Element Communication Protocol (PCEP) mechanisms are designed to be generic, which allows for future re-use outside of SR Policy. The new PCEP mechanisms are applicable to both stateless and stateful PCEP. Additionally, this document updates RFC 8231 and RFC 8281 to allow encoding of multiple Segment Lists in PCEP. 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. This document describes a mechanism used to collect Segment Routing (SR) 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, reoptimization, service placement, network visualization, etc. This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] Cisco Systems, Inc. Cisco Systems, Inc. Colt Huawei Nokia Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement in SR-MPLS networks using the Simple Two-Way Active Measurement Protocol (STAMP), as 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 SR-MPLS paths (including SR-MPLS Policies, SR-MPLS IGP best paths, and SR- MPLS IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SR-MPLS paths. Cisco Systems, Inc. Cisco Systems, Inc. Colt Huawei Nokia Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document describes the procedures for Performance Measurement for SRv6 using the Simple Two-Way Active Measurement Protocol (STAMP), as 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 SRv6 paths (including SRv6 Policies, SRv6 IGP best paths, and SRv6 IGP Flexible Algorithm paths), as well as Layer-3 and Layer-2 services over the SRv6 paths. 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. 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. The Segment Routing (SR) architecture leverages source routing and can be directly applied to the use of an MPLS data plane. A Segment Routing over MPLS (SR-MPLS) network may consist of multiple IGP domains or multiple Autonomous Systems (ASes) under the control of the same organization. It is useful to have the Label Switched Path (LSP) ping and traceroute procedures when an SR end-to-end path traverses multiple ASes or IGP domains. This document outlines mechanisms to enable efficient LSP ping and traceroute procedures in inter-AS and inter-domain SR-MPLS networks. This is achieved through a straightforward extension to the Operations, Administration, and Maintenance (OAM) protocol, relying solely on data plane forwarding for handling echo replies on transit nodes. Informative References 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. IEEE An Ethernet pseudowire (PW) is used to carry Ethernet/802.3 Protocol Data Units (PDUs) over an MPLS network. This enables service providers to offer "emulated" Ethernet services over existing MPLS networks. This document specifies the encapsulation of Ethernet/802.3 PDUs within a pseudowire. It also specifies the procedures for using a PW to provide a "point-to-point Ethernet" service. [STANDARDS-TRACK] This document describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing. [STANDARDS-TRACK] This document expands the applicability of Virtual Private Wire Service (VPWS) bit-stream payloads beyond Time Division Multiplexing (TDM) signals and provides pseudowire transport with complete signal transparency over Packet Switched Networks (PSNs). This document describes a method for encapsulating structured (NxDS0) Time Division Multiplexed (TDM) signals as pseudowires over packet-switching networks (PSNs). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams (see RFC 4553). This memo provides information for the Internet community. This document provides encapsulation formats and semantics for emulating Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) circuits and services over MPLS. [STANDARDS-TRACK] 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. This document presents Topology Independent Loop-Free Alternate (TI-LFA) Fast Reroute (FRR), which is aimed at providing protection of node and Adjacency segments within the Segment Routing (SR) framework. This FRR behavior builds on proven IP FRR concepts being LFAs, Remote LFAs (RLFAs), and Directed Loop-Free Alternates (DLFAs). 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 (PLR), reducing the operational need to control the tie-breaks among various FRR options. 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. 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 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 a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document defines Seamless Bidirectional Forwarding Detection (S-BFD), a simplified mechanism for using BFD with a large proportion of negotiation aspects eliminated, thus providing benefits such as quick provisioning, as well as improved control and flexibility for network nodes initiating path monitoring. This document updates RFC 5880.

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