China Mobile

No.32 XuanWuMen West Street Beijing, 100053 China hanliuyan@chinamobile.com

Huawei

Beiqing Road Beijing China zhangli344@huawei.com

China Mobile

No.32 XuanWuMen West Street Beijing, 100053 China wangminxue@chinamobile.com

Huawei

jie.dong@huawei.com

ZTE Corporation

Nanjing China chen.ran@zte.com.cn

General PCE Internet-Draft In some networks, the cross-layer planning and optimization is considered more efficient than independent planning and operation of the layer-3 and the underlying networks in terms of resource utilization and SLA assurance. This document extends the PCEP SRv6 for inter-layer network, which enable the PCE to instantiate candidate paths comprising both the layer-3 network segments and underlay network segments.

Introduction describes Path Computation Element Communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a PCE or between a pair of PCEs. specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with and defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide synchronization of LSP state between a PCC and a PCE or between a pair of PCEs, delegation of LSP control, reporting of LSP state from a PCC to a PCE, and controlling the setup and path routing of an LSP from a PCE to a PCC. further extends PCEP, providing a mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE. specifies PCEP extensions for supporting an SR-TE LSP for the MPLS data plane. extends to support SR for the IPv6 data plane. As defined in , Segment Routing (SR) architecture allows the source node to steer a packet through a path indicated by an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based, and it can have a semantic local to an SR node or global within an SR domain. Segment Routing over IPv6 (SRv6) enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Based on , defines a new SRv6 behavior, which can be used for steering packets to underlay network connections, so that the packet network layer can be integrated with the underlying layers efficiently to provide better SLA assurance. This document extends the PCEP SRv6 for inter-layer network, which enable the PCE to instantiate candidate paths comprising both the layer-3 network segments and underlay network segments.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Object Extensions

The ERO Object As specified in , an SR-TE path consists of one or more SIDs where each SID MAY be associated with the identifier that represents the node or adjacency corresponding to the SID. This identifier is referred to as the NAI. An NAI can be represented in various formats (e.g., IPv4 address, IPv6 address, etc). However, when an SRv6-TE path includes the END.IL SID defined in , the existing layer-3 NAIs are not applicable to the END.IL SID. Therefore, a new kind of NAI is needed for the END.IL SID. defines the "SRv6-ERO" subobject in the ERO to carry the SRv6 SID, the format of it is shown as follows:

SRv6-ERO Subobject Format

The NT field in this subobject indicates the type and format of the NAI contained in the object body. The value 2, 4 and 6 have been allocated for indicating different kind of NAI. This document request to allocate a new NT value for indicating the underlay network connection. Value TBD1: the NAI consists of a local IPv6 address, a Remote IPv6 address, and a underlay tunnel ID. This is used to identify the underlay network tunnel and used with the SRv6 inter-layer SID. The NAI associated with the new NT value is shown in the following figure:

NAI for Underlay Interface Identifier

This NAI is specified as a pair of global IPv6 address and an Underlay tunnel ID. It is used to describe an underaly network tunnel between two nodes identified by global IPv6 address. Each global IPv6 address is configured on a specific router, so together they identify a pair of routers at the end of the tunnel. The underlay tunnel ID is configured by the management system and uniquely identifies a underlay network tunnel within the source node.

The RRO Object A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per . The RRO on this message represents the SID list that was applied by the PCC, that is, the actual path taken. The procedures of with respect to the RRO apply equally to this specification without change. defines the SRv6-RRO subobject to carry the SRv6 SID applied by the PCC. The format of the SRv6-RRO subobject is the same as that of the SRv6-ERO subobject but without the L flag. The extension to the NT field of SRv6-ERO subobject is also applicable to the SRv6-RRO subobject.

Procedures TBD

Security Considerations TBD

IANA Considerations This document requests IANA to make the following allocations from the PCEP SRv6-ERO NAI Types sub-registry.

Value	Description	Reference
TBD1	NAI is an underlay interface identifier	This document

References Normative References 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 (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. China Mobile Huawei Technologies China Mobile ZTE Corporation China Mobile 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. Following the SRv6 Network Programming concept, this document defines SRv6 based mechanisms for inter-layer network programming, which can help to integrate the packet network layer with its underlying layers efficiently. For inter-layer path programming, a new SRv6 behavior is defined for steering packets to underlay network connections. The applicability of this new SRv6 behavior in typical scenarios is illustrated. 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 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] 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. The PCE model is described in the "PCE Architecture" document and facilitates path computation requests from Path Computation Clients (PCCs) to Path Computation Elements (PCEs). This document specifies generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs where cooperation between PCEs is desirable. Subsequent documents will specify application-specific requirements for the PCE communication protocol. This memo provides information for the Internet community. 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. 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. 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.