PCEP Extensions for Segment Routing leveraging the IPv6 data plane
draft-ietf-pce-segment-routing-ipv6-00
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9603.
|
|
---|---|---|---|
Authors | Mahendra Singh Negi , Cheng Li , Siva Sivabalan , Prejeeth Kaladharan | ||
Last updated | 2019-03-10 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 9603 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-pce-segment-routing-ipv6-00
PCE Working Group M. Negi Internet-Draft C. Li Intended status: Standards Track Huawei Technologies Expires: September 11, 2019 S. Sivabalan Cisco Systems P. Kaladharan RtBrick Inc March 10, 2019 PCEP Extensions for Segment Routing leveraging the IPv6 data plane draft-ietf-pce-segment-routing-ipv6-00 Abstract The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. 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 IGPs. A Segment Routed 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, Segment Routing can be applied to both MPLS and IPv6 forwarding plane, a PCE should be able to compute SR-Path for both MPLS and IPv6 forwarding plane. This draft describes the extensions required for Segment Routing support for IPv6 data plane in Path Computation Element communication Protocol (PCEP). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Negi, et al. Expires September 11, 2019 [Page 1] Internet-Draft PCEP Extensions for SRv6 March 2019 working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 11, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 3.3. Object Formats . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 6 3.3.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . 6 3.3.1.2. Exchanging the SRv6 Capability . . . . . . . . . 8 3.3.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . 9 3.3.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 9 3.3.3.1. SR-ERO Subobject . . . . . . . . . . . . . . . . 10 3.3.3.2. ERO Processing . . . . . . . . . . . . . . . . . 12 3.3.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 13 3.3.4.1. SR-RRO Subobject . . . . . . . . . . . . . . . . 13 3.4. Security Considerations . . . . . . . . . . . . . . . . . 14 3.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 14 3.5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . 14 3.5.1.1. ERROR Objects . . . . . . . . . . . . . . . . . . 14 3.5.1.2. TLV Type Indicators . . . . . . . . . . . . . . . 14 3.5.1.3. New Path Setup Type . . . . . . . . . . . . . . . 15 Negi, et al. Expires September 11, 2019 [Page 2] Internet-Draft PCEP Extensions for SRv6 March 2019 3.6. The NAI Type field . . . . . . . . . . . . . . . . . . . 15 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Normative References . . . . . . . . . . . . . . . . . . 15 5.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction As per [RFC8402], with Segment Routing (SR), 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 allows to enforce a flow through any path and service chain while maintaining per-flow state only at the ingress node of the SR domain. Segments can be derived from different components: IGP, BGP, Services, Contexts, Locater, etc. The list of segment forming the path is called the Segment List and is encoded in the packet header. Segment Routing can be applied to the IPv6 architecture with the Segment Routing Header (SRH) [I-D.ietf-6man-segment-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 of the packet. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment. Segment Routing use cases are described in [RFC7855] and [RFC8354]. Segment Routing protocol extensions are defined in [I-D.ietf-isis-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. As per [I-D.ietf-6man-segment-routing-header], an SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". Further details are in an illustration provided in [I-D.filsfils-spring-srv6-network-programming]. The SR architecture can be applied to the MPLS forwarding plane without any change, in which case an SR path corresponds to an MPLS Label Switching Path (LSP). The SR is applied to IPV6 forwarding plane using SRH. A SR path can be derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may be chosen by a suitable network planning tool, or a PCE and provisioned on the ingress node. Negi, et al. Expires September 11, 2019 [Page 3] Internet-Draft PCEP Extensions for SRv6 March 2019 [RFC5440] describes Path Computation Element communication Protocol (PCEP) for communication between a Path Computation Client (PCC) and a Path Computation Element (PCE) or between a pair of PCEs. A PCE or a PCC operating as a PCE (in hierarchical PCE environment) computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints and optimization criteria. [RFC8231] specifies extensions to PCEP that allow a stateful PCE to compute and recommend network paths in compliance with [RFC4657] 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, controlling the setup and path routing of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended for an operational model in which LSPs are configured on the PCC, and control over them is delegated to the PCE. A mechanism to dynamically initiate LSPs on a PCC based on the requests from a stateful PCE or a controller using stateful PCE is specified in [RFC8281]. As per [I-D.ietf-pce-segment-routing], it is possible to use a stateful PCE for computing one or more SR-TE paths taking into account various constraints and objective functions. Once a path is chosen, the stateful PCE can initiate an SR-TE path on a PCC using PCEP extensions specified in [RFC8281] using the SR specific PCEP extensions specified in [I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing] specifies PCEP extensions for supporting a SR-TE LSP for MPLS data plane. This document extends [I-D.ietf-pce-segment-routing] to support SR for IPv6 data plane. Additionally, using procedures described in this document, a PCC can request an SRv6 path from either stateful or a stateless PCE. This specification relies on the PATH-SETUP-TYPE TLV and procedures specified in [RFC8408]. This specification provides a mechanism for a network controller (acting as a PCE) to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For more information on the SR Policy Architecture, see [I-D.ietf-spring-segment-routing-policy]. 2. Terminology This document uses the following terms defined in [RFC5440]: PCC, PCE, PCEP Peer. This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation. The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. Negi, et al. Expires September 11, 2019 [Page 4] Internet-Draft PCEP Extensions for SRv6 March 2019 NAI: Node or Adjacency Identifier. PCC: Path Computation Client. PCE: Path Computation Element. PCEP: Path Computation Element Protocol. SR: Segment Routing. SID: Segment Identifier. SRv6: Segment Routing for IPv6 forwarding plane. SRH: IPv6 Segment Routing Header. SR Path: IPv6 Segment (List of IPv6 SID representing a path in IPv6 SR domain) 3. Overview of PCEP Operation in SRv6 Networks Basic operations for PCEP speakers is as per [I-D.ietf-pce-segment-routing]. SRv6 Paths computed by a PCE can be represented as an ordered list of SRv6 segments of 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment" in this document. [I-D.ietf-pce-segment-routing] defined a new ERO subobject denoted by "SR-ERO subobject" capable of carrying a SID as well as the identity of the node/adjacency represented by the SID. SR-capable PCEP speakers should be able to generate and/or process such ERO subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Initiate Request message (PCInitiate) defined in [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in defined in [RFC8231]. This document extends the "SR-ERO subobject" defined in [I-D.ietf-pce-segment-routing] to carry IPv6 SID(s) (IPv6 Addresses). SRv6-capable PCEP speakers MUST be able to generate and/or process this. When a PCEP session between a PCC and a PCE is established, both PCEP speakers exchange their capabilities to indicate their ability to support SRv6 specific functionality. In summary, this document: Negi, et al. Expires September 11, 2019 [Page 5] Internet-Draft PCEP Extensions for SRv6 March 2019 o Defines a new PCEP capability for SRv6 o Update the SR-ERO and SR-RRO sub-object for SRv6 o Defines a new path setup type carried in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs. 3.1. Operation Overview In SR networks, an ingress node of an SR path appends all outgoing packets with an SR header consisting of a list of SIDs (IPv6 Prefix in case of SRv6). The header has all necessary information to guide the packets from the ingress node to the egress node of the path, and hence there is no need for any signaling protocol. For IPv6 in control plane with MPLS data-plane, mechanism remains same as [I-D.ietf-pce-segment-routing] This document describes extensions to SR path for IPv6 data plane. SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see details in Figure 2). A PCC or PCE indicates its ability to support SRv6 during the PCEP session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV (see details in Section 3.3.1.1). 3.2. SRv6-Specific PCEP Message Extensions As defined in [RFC5440], a PCEP message consists of a common header followed by a variable length body made up of mandatory and/or optional objects. This document does not require any changes in the format of PCReq and PCRep messages specified in [RFC5440], PCInitiate message specified in [RFC8281], and PCRpt and PCUpd messages specified in [RFC8231]. However, PCEP messages pertaining to SRv6 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly identify that SRv6 is intended. 3.3. Object Formats 3.3.1. The OPEN Object 3.3.1.1. The SRv6 PCE Capability sub-TLV This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, as follows: o PST = TBD2: Path is setup using SRv6. Negi, et al. Expires September 11, 2019 [Page 6] Internet-Draft PCEP Extensions for SRv6 March 2019 A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list. This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. If a PCEP speaker includes PST=TBD2 in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the SRv6-PCE- CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the following figure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: SRv6-PCE-CAPABILITY sub-TLV format The code point for the TLV type (TBD1) is to be defined by IANA. The TLV length is variable. The value comprise of - Reserved: 2 octet, this field MUST be set to 0 on transmission, and ignored on receipt. Flags: 2 octet, one bit is currently assigned in this document. L bit: A PCC sets this bit to 1 to indicate that it does not impose any limit on MSD (irrespective of the MSD-Type). Unassigned bits MUST be set to 0 and ignored on receipt. Negi, et al. Expires September 11, 2019 [Page 7] Internet-Draft PCEP Extensions for SRv6 March 2019 A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per the IGP MSD Type registry created by [RFC8491] and populated with SRv6 MSD types as per [I-D.bashandy-isis-srv6-extensions]; MSD- Value (1 octet) is as per [RFC8491]. The TLV format is compliant with the PCEP TLV format defined in [RFC5440]. That is, the TLV is composed of 2 octets for the type, 2 octets specifying the TLV length, and a Value field. The Length field defines the length of the value portion in octets. The TLV is padded to 4-octet alignment, and padding is not included in the Length field. The number of (MSD-Type,MSD-Value) pairs can be determined from the Length field of the TLV. 3.3.1.2. Exchanging the SRv6 Capability A PCC indicates that it is capable of supporting the head-end functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCE. A PCE indicates that it is capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message that it sends to a PCC. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a PCErr message with Error- Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then close the PCEP session. If a PCEP speaker receives a PATH-SETUP- TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=TBD2, then the PCEP speaker MUST ignore the SRv6-PCE-CAPABILITY sub-TLV. The number of SRv6 SIDs that can be imposed on a packet depends on the PCC's IPv6 data plane's capability. If a PCC sets the L flag to 1 then the MSD is not used and MUST not be included. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that the sender can impose any length of SRH. If a PCC sets the L flag to zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag and SRv6 MSD-Type, MSD-Value fields both set to zero then it is considered as an error and the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV received by the PCE does not correspond to one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session establishment failure" and Error-Value=1 "reception of an invalid Open message or a non Open message."). Negi, et al. Expires September 11, 2019 [Page 8] Internet-Draft PCEP Extensions for SRv6 March 2019 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the PCC node. However, if a PCE learns these via different means, e.g routing protocols, as specified in: [I-D.li-ospf-ospfv3-srv6-extensions]; [I-D.bashandy-isis-srv6-extensions]; [I-D.dawra-idr-bgpls-srv6-ext], then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a PCE learns the other advanced SRv6 MSD via different means, it MUST use that value regardless of the values exchanged in the SRv6-PCE-CAPABILITY sub-TLV. Once an SRv6-capable PCEP session is established with a non-zero SRv6 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD Type). If a PCC needs to modify the SRv6 MSD value, it MUST close the PCEP session and re-establish it with the new value. If a PCEP session is established with a non-zero SRv6 MSD value, and the PCC receives an SRv6 path containing more SIDs than specified in the SRv6 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr message with Error-Type 10 (Reception of an invalid object) and Error-Value 3 (Unsupported number of Segment ERO subobjects). If a PCEP session is established with an SRv6 MSD value of zero, then the PCC MAY specify an SRv6 MSD for each path computation request that it sends to the PCE, by including a "maximum SID depth" metric object on the request similar to [I-D.ietf-pce-segment-routing]. The L flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- CAPABILITY sub-TLV are meaningful only in the Open message sent from a PCC to a PCE. As such, a PCE MUST set the L flag and not include (MSD-Type,MSD-Value) in an outbound message to a PCC. Similarly, a PCC MUST ignore any (MSD-Type,MSD-Value) received from a PCE. If a PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open message, it processes only the first sub-TLV received. 3.3.2. The RP/SRP Object In order to indicate the SRv6 path, RP or SRP object MUST include the PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a new Path Setup Type (PST=TBD2) for SRv6. The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 3.3.3. ERO Object In order to support SRv6, the SR-ERO subobject is used [I-D.ietf-pce-segment-routing]. This documents extends the SR-ERO subobject. All the processing rules remains the same. Negi, et al. Expires September 11, 2019 [Page 9] Internet-Draft PCEP Extensions for SRv6 March 2019 3.3.3.1. SR-ERO Subobject For supporting SRv6, a new NAI Type (NT) is defined, the format of SR-ERO sub object remains the same as defined in [I-D.ietf-pce-segment-routing]. When the NAI Type (NT) indicates SRv6, then the SR-ERO subobject represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) in place of NAI (Node or Adjacency Identifier) defined in [I-D.ietf-pce-segment-routing]. The 32 bit SID is not used for SRv6 and MUST NOT be included. The format of SR-ERO subobject is reproduced with the SRv6I field as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |L| Type | Length | NT | Flags |F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (not included) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SRv6I (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: SR-ERO Subobject Format The description of all the flags and fields is as per [I-D.ietf-pce-segment-routing]. For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3. For SRv6 segments (when NT is TBD3), M and C flag MUST NOT be set. The S flag MUST be set and SID field MUST NOT be included. The F bit MUST NOT be set. If these flags are not set properly, the subobject MUST be considered malformed and the PCEP speaker react as per the error handling described in Section 3.3.3.2. The SRv6I format is as shown below: Negi, et al. Expires September 11, 2019 [Page 10] Internet-Draft PCEP Extensions for SRv6 March 2019 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SRv6 Identifier | | (128-bit) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SRv6NT| Flags | Function Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // NAI (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: SR-ERO Subobject's SRv6I Format SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6 segment. SRv6NT is the SRv6 NAI Type which indicates the interpretation for NAI (Node or Adjacency Identifier) as per [I-D.ietf-pce-segment-routing]. Flags is the 12 bit field, no flag bits are currently defined in this document. This MUST be set to 0 and ignored on receipt. Function Code is is the 16 bit field representing supported functions associated with SRv6 SIDs. This information is optional and included only for maintainability. Following function codes are currently defined - 0: Reserved 1: End Function 2: End.DX6 Function 3: End.DT6 Function 4: End.X Function NAI field [I-D.ietf-pce-segment-routing] contains the NAI associated with the SRv6 Identifier. Depending on the value of SRv6NT, the NAI can have different formats. When SRv6NT value is 1, the NAI is as per the 'IPv6 Node ID' format defined in [I-D.ietf-pce-segment-routing], which specify an IPv6 address. This is used to identify the owner of the Negi, et al. Expires September 11, 2019 [Page 11] Internet-Draft PCEP Extensions for SRv6 March 2019 SRv6 Identifier. This is optional, as the LOC (the locater portion) of the SRv6 SID serves a similar purpose. When SRv6NT value is 2, the NAI is as per the 'IPv6 Adjacency' format defined in [I-D.ietf-pce-segment-routing], which specify a pair of IPv6 addresses. This is used to identify the IPv6 Adjacency and used with the SRv6 Adj-SID. Note that when SRv6NT value is 0, NAI is not included and MUST be NULL. [Editor's Note - Add IPv6 unnumbered adjacency, once done by [I-D.ietf-pce-segment-routing]] 3.3.3.2. ERO Processing The ERO and SR-ERO subobject processing remains as per [RFC5440] and [I-D.ietf-pce-segment-routing]. The NT MUST only be TDB3, if the PST=TBD3 is set in the PCEP message and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the PCEP peer. In case a PCEP speaker receives the SR-ERO subobject with NT indicating SRv6 segment, when the PST is not set to TBD3 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it MUST send a PCErr message with Error- Type = 19 ("Invalid Operation") and Error-Value = TBD4 ("Attempted SRv6 when the capability was not advertised"). A PCEP speaker that does not recognize the NT value, it would behave as per [I-D.ietf-pce-segment-routing]. If a PCC receives a list of SRv6 segments, and the number of SRv6 segments exceeds the SRv6 MSD that the PCC can impose on the packet (SRH), it MAY send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD ("Unsupported number of Segment ERO subobjects") as per [I-D.ietf-pce-segment-routing]. When a PCEP speaker detects that all subobjects of ERO are not identical to SRv6, and if it does not handle such ERO, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = TBD ("Non-identical ERO subobjects")as per [I-D.ietf-pce-segment-routing]. When a PCEP speaker receives an SR-ERO subobject for SRv6 segment, M, C and F flag MUST NOT be set and S flag MUST be set. Otherwise, it MUST consider the entire ERO object invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error- Value = TBD ("Malformed object") as per [I-D.ietf-pce-segment-routing]. The PCEP speaker MAY include the malformed SR-ERO object in the PCErr message as well. Negi, et al. Expires September 11, 2019 [Page 12] Internet-Draft PCEP Extensions for SRv6 March 2019 3.3.3.2.1. Interpreting the SR-ERO The SR-ERO contains a sequence of subobjects. According to [I-D.ietf-spring-segment-routing-policy], each SR-ERO subobject in the sequence identifies a segment that the traffic will be directed to, in the order given. That is, the first subobject identifies the first segment the traffic will be directed to, the second SR-ERO subobject represents the second segment, and so on. The PCC interprets the SR-ERO by converting it to an SRv6 SRH plus a next hop. The PCC sends packets along the segment routed path by prepending the SRH onto the packets and sending the resulting, modified packet to the next hop. 3.3.4. RRO Object In order to support SRv6, the SR-RRO Subobject is used [I-D.ietf-pce-segment-routing]. All other processing rules remains the same. 3.3.4.1. SR-RRO Subobject For SRv6 segments, a new NT (NAI Type) is assigned by IANA as TBD3, the format of SR-RRO sub object remains the same as the SR-ERO subobject, but without the L flag [I-D.ietf-pce-segment-routing]. When the NAI Type (NT) indicates SRv6, then the SR-RRO subobject represent a SRv6 segment and include a field SRv6I (SRv6 Identifier) in place of NAI (Node or Adjacency Identifier) defined in [I-D.ietf-pce-segment-routing]. The 32 bit SID MUST NOT be included. The format of SR-RRO subobject is reproduced with the SRv6I field as shown below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | ST | Flags |F|S|C|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (not included) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SRv6I (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: SR-RRO Subobject Format The description of all fields and flags is as per SR-ERO subobject. Negi, et al. Expires September 11, 2019 [Page 13] Internet-Draft PCEP Extensions for SRv6 March 2019 Processing rules of SR-RRO subobject are identical to those of SR-ERO subobject. If a PCE detects that all subobjects of RRO are not identical, and if it does not handle such RRO, it MUST send a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-Value = 10 ("Non-identical RRO subobjects"). 3.4. Security Considerations The security considerations described in [RFC5440], [RFC8231] and [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this specification. No additional security measure is required. 3.5. IANA Considerations This document requests IANA to include (I) bit in flags registry for SR-ERO and SR-RRO sub-objects. Other changes are defined as: 3.5.1. PCEP Objects 3.5.1.1. ERROR Objects IANA is requested to allocate code-points in the PCEP-ERROR Object Error Types and Values registry for the following new error-values: Error-Type Meaning ---------- ------- 10 Reception of an invalid object Error-value = TBD5 (Missing PCE-SRv6-CAPABILITY sub-TLV) 19 Invalid Operation Error-value = TBD4 (Attempted SRv6 when the capability was not advertised) 3.5.1.2. TLV Type Indicators IANA is requested to make the assignment of the new code points for the existing "PCEP TLV Type Indicators" registry as follows: Value Meaning Reference ----- ------- --------- TBD1 SRv6-PCE-CAPABILITY This Document Negi, et al. Expires September 11, 2019 [Page 14] Internet-Draft PCEP Extensions for SRv6 March 2019 3.5.1.3. New Path Setup Type [RFC8408] defines the PATH-SETUP-TYPE TLV and requests that IANA creates a registry to manage the value of the PATH-SETUP-TYPE TLV's PST field. IANA is requested to allocate a new code point in the PCEP PATH_SETUP_TYPE TLV PST field registry, as follows: Value Description Reference ----- ----------- --------- TBD2 SRv6 (SRH) technique This Document 3.6. The NAI Type field As per [I-D.ietf-pce-segment-routing], a new subregistery for "PCEP SR-ERO NAI Types" was created. IANA is requested to make the assignment of the new code points in the afore-mentioned registry as follows: Value Description Reference ----- ------- --------- TBD3 NAI is an SRv6 segment This Document 4. Acknowledgements The authors would like to thank Jeff Tentsura for suggestions regarding SRv6 MSD Types. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>. Negi, et al. Expires September 11, 2019 [Page 15] Internet-Draft PCEP Extensions for SRv6 March 2019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, <https://www.rfc-editor.org/info/rfc8231>. [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>. [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>. [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, <https://www.rfc-editor.org/info/rfc8408>. [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, <https://www.rfc-editor.org/info/rfc8491>. [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-16 (work in progress), March 2019. 5.2. Informative References [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>. Negi, et al. Expires September 11, 2019 [Page 16] Internet-Draft PCEP Extensions for SRv6 March 2019 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., Litkowski, S., Horneffer, M., and R. Shakir, "Source Packet Routing in Networking (SPRING) Problem Statement and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 2016, <https://www.rfc-editor.org/info/rfc7855>. [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>. [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., Ed., and M. Townsley, "Use Cases for IPv6 Source Packet Routing in Networking (SPRING)", RFC 8354, DOI 10.17487/RFC8354, March 2018, <https://www.rfc-editor.org/info/rfc8354>. [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-16 (work in progress), February 2019. [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-22 (work in progress), December 2018. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-23 (work in progress), January 2019. [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "Segment Routing Policy Architecture", draft-ietf-spring-segment-routing- policy-02 (work in progress), October 2018. [I-D.filsfils-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 Network Programming", draft-filsfils-spring-srv6-network- programming-07 (work in progress), February 2019. Negi, et al. Expires September 11, 2019 [Page 17] Internet-Draft PCEP Extensions for SRv6 March 2019 [I-D.li-ospf-ospfv3-srv6-extensions] Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, "OSPFv3 Extensions for SRv6", draft-li-ospf- ospfv3-srv6-extensions-03 (work in progress), March 2019. [I-D.bashandy-isis-srv6-extensions] Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and Z. Hu, "IS-IS Extensions to Support Routing over IPv6 Dataplane", draft-bashandy-isis-srv6-extensions-05 (work in progress), March 2019. [I-D.dawra-idr-bgpls-srv6-ext] Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., daniel.bernier@bell.ca, d., Uttaro, J., Decraene, B., and H. Elmalky, "BGP Link State Extensions for SRv6", draft- dawra-idr-bgpls-srv6-ext-05 (work in progress), March 2019. Negi, et al. Expires September 11, 2019 [Page 18] Internet-Draft PCEP Extensions for SRv6 March 2019 Appendix A. Contributor The following persons contributed to this document: Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: dhruv.ietf@gmail.com Huang Wumin Huawei Technologies Huawei Building, No. 156 Beiqing Rd. Beijing 100095 China Email: huangwumin@huawei.com Authors' Addresses Mahendra Singh Negi Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India EMail: mahendrasingh@huawei.com Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China EMail: chengli13@huawei.com Siva Sivabalan Cisco Systems EMail: msiva@cisco.com Negi, et al. Expires September 11, 2019 [Page 19] Internet-Draft PCEP Extensions for SRv6 March 2019 Prejeeth Kaladharan RtBrick Inc Bangalore, Karnataka India EMail: prejeeth@rtbrick.com Negi, et al. Expires September 11, 2019 [Page 20]