PCE Working Group                                                M. Negi
Internet-Draft                                                     C. Li
Intended status: Standards Track                     Huawei Technologies
Expires: September 11, October 9, 2019                                    S. Sivabalan
                                                           Cisco Systems
                                                           P. Kaladharan
                                                             RtBrick Inc
                                                          March 10,
                                                             Z. Yongqing
                                                           China Telecom
                                                           April 7, 2019

   PCEP Extensions for Segment Routing leveraging the IPv6 data plane
                 draft-ietf-pce-segment-routing-ipv6-00
                 draft-ietf-pce-segment-routing-ipv6-01

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

   Since SR 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 document describes the extensions required for Segment Routing SR
   support for IPv6 data plane in Path Computation Element communication
   Protocol (PCEP).  The PCEP extension and mechanism to support SR-MPLS
   is described in [I-D.ietf-pce-segment-routing].  This document
   extends it to support SRv6 (SR over IPv6).

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, [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
   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, October 9, 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   5
   3.  Overview of PCEP Operation in SRv6 Networks . . . . . . . . .   5
     3.1.  Operation Overview  . . . . . . . . . . . . . . . . . . .   6
     3.2.  SRv6-Specific PCEP Message Extensions . . . . . . . . . .   6
     3.3.
   4.  Object Formats  . . . . . . . . . . . . . . . . . . . . .   6
       3.3.1. . .   7
     4.1.  The OPEN Object . . . . . . . . . . . . . . . . . . .   6
         3.3.1.1. . .   7
       4.1.1.  The SRv6 PCE Capability sub-TLV . . . . . . . . .   6
         3.3.1.2.  Exchanging the SRv6 Capability . .   7
     4.2.  The RP/SRP Object . . . . . . . . . . . . . . . . . . . .   8
       3.3.2.  The RP/SRP Object
     4.3.  ERO . . . . . . . . . . . . . . . . . .   9
       3.3.3.  ERO Object . . . . . . . . .   8
       4.3.1.  SRv6-ERO Subobject  . . . . . . . . . . . .   9
         3.3.3.1.  SR-ERO . . . . .   8
     4.4.  RRO . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
       4.4.1.  SRv6-RRO Subobject  . . . . . . . . . . . . . . . .  10
         3.3.3.2. .  11
   5.  Procedures  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Exchanging the SRv6 Capability  . . . . . . . . . . . . .  11
     5.2.  ERO Processing  . . . . . . . . . . . . . . . . .  12
       3.3.4.  RRO Object . . . .  13
       5.2.1.  SRv6 ERO Validation . . . . . . . . . . . . . . . . .  13
         3.3.4.1.  SR-RRO Subobject
       5.2.2.  Interpreting the SRv6-ERO . . . . . . . . . . . . . .  14
     5.3.  RRO Processing  . . . .  13
     3.4.  Security Considerations . . . . . . . . . . . . . . . . .  14
     3.5.  IANA
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
       3.5.1.  PCEP Objects  15
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . .  14
         3.5.1.1.  ERROR Objects .  15
     7.1.  PCEP ERO and RRO subobjects . . . . . . . . . . . . . . .  15
     7.2.  New SRv6-ERO Flag Registry  . . . .  14
         3.5.1.2.  TLV . . . . . . . . . . .  15
     7.3.  PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators  . . .  16
     7.4.  SRv6 PCE Capability Flags . . . . . . . . . . . . .  14
         3.5.1.3. . . .  16
     7.5.  New Path Setup Type . . . . . . . . . . . . . . .  15

     3.6.  The NAI Type field . . . .  17
     7.6.  ERROR Objects . . . . . . . . . . . . . . .  15
   4. . . . . . . .  17
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   5.  17
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.1.  17
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     5.2.  17
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  16  19
   Appendix A.  Contributor  . . . . . . . . . . . . . . . . . . . .  19  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  21

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

   [RFC5440] describes

   [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  [RFC8231]specifies
   extensions to PCEP that allow a stateful PCE to compute and recommend
   network paths in compliance with [RFC4657] and [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 [RFC8281]using the SR
   specific PCEP extensions specified in [I-D.ietf-pce-segment-routing].
   [I-D.ietf-pce-segment-routing] specifies
   [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
   [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].

   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

   [I-D.ietf-pce-segment-routing]defined a new ERO Explicit Route Object
   (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 define new subobjects "SRv6-ERO" and "SRv6-RRO" in
   [I-D.ietf-pce-segment-routing] ERO
   and RRO respectively to carry IPv6 SID(s) SRv6 SID (IPv6 Addresses). Address).  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:

   o  Defines a new PCEP capability for SRv6 SRv6.

   o  Update the SR-ERO and SR-RRO sub-object for SRv6  Defines a new subobject SRv6-ERO in ERO.

   o  Defines a new subobject SRv6-RRO in RRO.

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

4.  Object Formats

3.3.1.

4.1.  The OPEN Object

3.3.1.1.

4.1.1.  The SRv6 PCE Capability sub-TLV

   This document defines a new Path Setup Type (PST) [RFC8408] for [RFC8408]for SRv6,
   as follows:

   o  PST = TBD2: Path is setup using SRv6.

   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|         |N|X|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   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 two bits are currently assigned in this document.

         L

         N bit: A PCC sets this flag bit to 1 to indicate that it is
         capable of resolving a Node or Adjacency Identifier (NAI) to a
         SRv6-SID.

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

      A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per
      the IGP MSD Type registry created by [RFC8491] and [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

4.2.  The RP/SRP Object

   In order to a PCE.  A PCE indicates that it is
   capable of computing indicate the SRv6 paths by including path, RP or SRP object MUST include the SRv6-PCE-CAPABILITY
   sub-TLV
   PATH-SETUP-TYPE TLV specified in the Open message that it sends to a PCC.

   If a PCEP speaker receives [RFC8408].  This document defines a PATH-SETUP-TYPE-CAPABILITY
   new Path Setup Type (PST=TBD2) for SRv6.

   The LSP-IDENTIFIERS TLV with a
   PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is
   absent, then MAY be present for the PCEP speaker MUST send a PCErr message with Error-
   Type 10 (Reception of an invalid object) above PST type.

4.3.  ERO

   In order to support SRv6, new subobjects "SRv6-ERO" and Error-Value TBD5 (to be
   assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) "SRv6-RRO"
   are defined in ERO and MUST then
   close RRO respectively.

4.3.1.  SRv6-ERO Subobject

   An SRv6-ERO subobject is formatted as shown in the PCEP session.  If a PCEP speaker receives a PATH-SETUP-
   TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but following diagram.

       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=TBD3 |     Length    | NT    |     Flags         |F|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              reserved           |       Function Code         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      SRv6 SID (optional)                      |
      |                     (128-bit)                                 |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                    NAI (variable, optional)                 //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: SRv6-ERO Subobject Format

   The fields in the PST
   list does not contain PST=TBD2, then SRv6-ERO Subobject are as follows:

   The 'L' Flag: Indicates whether the PCEP speaker subobject represents a loose-hop
   (see [RFC3209]).  If this flag is set to zero, a PCC MUST ignore NOT
   overwrite the
   SRv6-PCE-CAPABILITY sub-TLV.

   The number of SRv6 SIDs that can be imposed on a packet depends on SID value present in the PCC's IPv6 data plane's capability.  If SRv6-ERO subobject.
   Otherwise, a PCC sets MAY expand or replace one or more SID values in the L flag
   received SRv6-ERO based on its local policy.

   Type: Set to
   1 then TBD3.

   Length: Contains the MSD is not used total length of the subobject in octets.  The
   Length MUST be at least 24, and MUST not be included.  If a PCE
   receives multiple of 4.  An SRv6-ERO
   subobject MUST contain at least one of a SRv6-SID or an SRv6-PCE-CAPABILITY sub-TLV with NAI.  The
   flags described below indicate whether the L flag set to 1 then
   it MUST ignore any MSD-Type, MSD-Value SRv6-SID or NAI fields are
   absent.

   NAI Type (NT): Indicates the type and MUST assume that format of the sender can impose NAI contained in
   the object body, if any length of SRH. is present.  If a PCC sets the L flag F bit is set to
   zero, zero (see
   below) 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 NT field has no meaning and SRv6 MSD-Type, MSD-Value fields both set to zero
   then it MUST be ignored by the
   receiver.  This document reuses NT types defined in
   [I-D.ietf-pce-segment-routing]:

      If NT value is considered as an error and 0, the PCE NAI 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 NOT be included.

      When NT value is 2, the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV
   received by NAI is as per the PCE does not correspond 'IPv6 Node ID' format
      defined in [I-D.ietf-pce-segment-routing], which specifies an IPv6
      address.  This is used to one identify the owner of the SRv6 MSD types,
      Identifier.  This is optional, as the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session
   establishment failure" and Error-Value=1 "reception LOC (the locater portion) of an invalid
   Open message or a non Open message.").

   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 serves a PCE learns these via different means, e.g
   routing protocols, similar purpose (when present).

      When NT value is 3, the NAI is 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 per the values 'IPv6 Adjacency' format
      defined in the SRv6-PCE-CAPABILITY sub-TLV.
   Furthermore, whenever [I-D.ietf-pce-segment-routing], which specify a PCE learns pair of
      IPv6 addresses.  This is used to identify the IPv6 Adjacency and
      used with the other advanced SRv6 MSD via
   different means, it MUST use that Adj-SID.

      When NT value regardless of the values
   exchanged in is 6, the SRv6-PCE-CAPABILITY sub-TLV.

   Once an SRv6-capable PCEP session NAI is established with a non-zero SRv6
   MSD value, as per the corresponding PCE MUST NOT send SRv6 paths with 'link-local IPv6
      addresses' format defined in [I-D.ietf-pce-segment-routing], which
      specify a
   number pair of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD
   Type).  If a PCC needs (global IPv6 address, interface ID) tuples.  It
      is used to modify the SRv6 MSD value, it MUST close identify the PCEP session IPv6 Adjacency and re-establish it with the new value.  If a PCEP
   session is established used with a non-zero SRv6 MSD value, and the PCC
   receives an SRv6 path containing more SIDs than specified Adj-
      SID.

      SR-MPLS specific NT types are not valid in SRv6-ERO.

   Flags: Used to carry additional information pertaining to the SRv6
   MSD value (based on the SRv6 MSD type),
   SRv6-SID.  This document defines the PCC following flag bits.  The other
   bits MUST send a PCErr
   message with Error-Type 10 (Reception of an invalid object) be set to zero by the sender and
   Error-Value 3 (Unsupported number of Segment ERO subobjects).  If a
   PCEP session MUST be ignored by the
   receiver.

   o  S: When this bit is established with an SRv6 MSD set to 1, the SRv6-SID value of zero, then in the subobject
      body is absent.  In this case, the PCC MAY specify an SRv6 MSD is responsible for each path computation request that it
   sends to choosing
      the PCE, SRv6-SID value, e.g., by including a "maximum SID depth" metric object on looking up in the request similar to [I-D.ietf-pce-segment-routing].

   The L flag and (MSD-Type,MSD-Value) pair inside SR-DB using the SRv6-PCE-
   CAPABILITY sub-TLV are meaningful only NAI
      which, in this case, MUST be present in the Open message sent from
   a PCC subobject.  If the S
      bit is set to a PCE.  As such, a PCE 1 then F bit MUST be 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 zero.

   o  F: When this bit is set to 1, the NAI value in an Open
   message, it processes only the first sub-TLV received.

3.3.2. subobject body
      is absent.  The RP/SRP Object

   In order F bit MUST be set to indicate the SRv6 path, RP or SRP object 1 if NT=0, and otherwise MUST include the
   PATH-SETUP-TYPE TLV specified in [RFC8408].  This document defines a
   new Path Setup Type (PST=TBD2) for SRv6.
      be set to zero.  The LSP-IDENTIFIERS TLV MAY S and F bits MUST NOT both be present for the above PST type.

3.3.3.  ERO Object

   In order set to support SRv6, the SR-ERO subobject is used
   [I-D.ietf-pce-segment-routing]. 1.

   Function Code: A 16 bit field representing supported functions
   associated with SRv6 SIDs.  This documents extends information is optional and plays no
   role in the SR-ERO
   subobject.  All SRH imposed on the processing rules remains packet.  It could be included for
   maintainability and diagnostic purpose.  If function code is not
   defined 0 is used.  Functions codes are defined in
   [I-D.filsfils-spring-srv6-network-programming].

   SRv6 SID: SRv6 Identifier is the same.

3.3.3.1.  SR-ERO Subobject

   For supporting SRv6, a new 128 bit IPv6 addresses representing
   the SRv6 segment.

   NAI: The NAI Type (NT) is defined, associated with the SRv6-SID.  The NAI's format of
   SR-ERO sub object remains depends
   on the same as defined value in
   [I-D.ietf-pce-segment-routing].

   When the NAI Type (NT) indicates SRv6, then the SR-ERO subobject
   represent a SRv6 segment NT field, and include a field SRv6I (SRv6 Identifier) is described in place
   [I-D.ietf-pce-segment-routing].

   At least one of the SRv6-SID and the NAI (Node or Adjacency Identifier) defined MUST be included in
   [I-D.ietf-pce-segment-routing].  The 32 bit SID is not used for SRv6 the
   SRv6-ERO subobject, and MUST NOT both MAY be included.  The format of SR-ERO subobject is
   reproduced with

4.4.  RRO

4.4.1.  SRv6-RRO Subobject

   A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per
   [RFC8231].  The RRO on this message represents the SRv6I field as SID list that was
   applied by the PCC, that is, the actual path taken.  The procedures
   of [I-D.ietf-pce-segment-routing]with respect to the RRO apply
   equally to this specification without change.

   An RRO contains one or more subobjects called "SRv6-RRO subobjects"
   whose format is 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
      |   Type=TBD4   |     Length    |  NT   |     Flags     |F|S|C|M|         |F|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              reserved           |       Function Code         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      SRv6 SID (not included)                                 |
      |                     (128-bit)                                 |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                     SRv6I                    NAI (variable)                           //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: SR-ERO 3: SRv6-RRO Subobject Format

   The description format of all the flags and fields SRv6-RRO subobject is the same as that of the
   SRv6-ERO subobject, but without the L flag.

   Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as
   per [I-D.ietf-pce-segment-routing].

   For

5.  Procedures

5.1.  Exchanging the SRv6 segments, a new NT (NAI Type) Capability

   A PCC indicates that it is assigned by IANA as TBD3.

   For capable of supporting the head-end
   functions for SRv6 segments (when NT by including the SRv6-PCE-CAPABILITY sub-TLV in
   the Open message that it sends to a PCE.  A PCE indicates that it 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,
   capable of computing SRv6 paths by including the subobject MUST be considered
   malformed and SRv6-PCE-CAPABILITY
   sub-TLV in the Open message that it sends to a PCC.

   If a PCEP speaker react as per receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
   PST list containing PST=TBD2, but the error handling
   described in Section 3.3.3.2.

   The SRv6I format SRv6-PCE-CAPABILITY sub-TLV is 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
   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 X flag to
   1 2 3 4 5 6 7 8 9 0 then the MSD is not used and MUST NOT be included.  If a PCE
   receives an SRv6-PCE-CAPABILITY sub-TLV with the X 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 X 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 X 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.").

   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 Identifier                          |
   |                         (128-bit)                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRv6NT|         Flags           |       Function Code         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        NAI (variable)                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 3: SR-ERO Subobject's SRv6I Format MSD
   Type).  If a PCC needs to modify the SRv6 Identifier 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 128 bit IPv6 addresses representing PCC
   receives an SRv6
      segment.

      SRv6NT 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 N flag, X 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 flags to zero and not
   include any (MSD-Type, MSD-Value) pair in the SRv6-PCE-CAPABILITY
   sub-TLV in an outbound message to a PCC.  Similarly, a PCC MUST
   ignore N, X flag and any (MSD-Type,MSD-Value) pair 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.

5.2.  ERO Processing

   The ERO processing remains as per [RFC5440]and
   [I-D.ietf-pce-segment-routing].

5.2.1.  SRv6 ERO Validation

   If a PCC does not support the SRv6 NAI Type which indicates PCE Capability and thus cannot
   recognize the interpretation for
      NAI (Node SRv6-ERO or Adjacency Identifier) as SRv6-RRO subobjects, it will respond
   according to the rules for a malformed object per
      [I-D.ietf-pce-segment-routing].

      Flags is [RFC5440].

   On receiving an SRv6-ERO, a PCC MUST validate that the 12 bit Length field, no flag bits
   the S bit, the F bit and the NT field are currently defined in
      this document.  This consistent, as follows.

   o  If NT=0, the F bit MUST be set to 0 and ignored on receipt.

      Function Code is is 1, the 16 S bit field representing supported
      functions associated with SRv6 SIDs.  This information is optional MUST be zero 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
      Length MUST be 24.

   o  If NT=2, the value of
      SRv6NT, F bit MUST be zero.  If the NAI can have different formats.

         When SRv6NT value S bit is 1, the NAI is as per Length
      MUST be 24, otherwise the 'IPv6 Node ID'
         format defined in [I-D.ietf-pce-segment-routing], which specify
         an IPv6 address.  This is used to identify Length MUST be 40.

   o  If NT=4, the owner of F bit MUST be zero.  If the
         SRv6 Identifier.  This S bit is optional, as 1, the LOC (the locater
         portion) of Length
      MUST be 40, otherwise the SRv6 SID serves a similar purpose.

         When SRv6NT value is 2, Length MUST be 56.

   o  If NT=6, the NAI is as per F bit MUST be zero.  If the 'IPv6 Adjacency'
         format defined in [I-D.ietf-pce-segment-routing], which specify
         a pair of IPv6 addresses.  This S bit is used to identify 1, the IPv6
         Adjacency and used with Length
      MUST be 48, otherwise the SRv6 Adj-SID.

         Note that when SRv6NT value is 0, NAI is Length MUST be 64.

   o  NT types (1, 3, and 5) are not included valid for SRv6.

   If a PCC finds that the NT field, Length field, S bit and F bit are
   not consistent, it 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 consider the entire ERO invalid 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 send
   a PCErr message
   and SRv6-PCE-CAPABILITY sub-TLV is exchanged with the Error-Type = 10 ("Reception of an invalid
   object") and Error-Value = 11 ("Malformed object").

   If a PCEP peer. speaker that does not recognize the NT value received in
   SRv6-ERO subobject, it would behave as per
   [I-D.ietf-pce-segment-routing].

   In case a PCEP speaker receives the SR-ERO subobject with NT indicating
   SRv6 segment, SRv6-ERO subobject, when the PST
   is not set to TBD3 TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged,
   it MUST send a PCErr message with Error-
   Type Error-Type = 19 ("Invalid
   Operation") and Error-Value = TBD4 TBD5 ("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 MUST 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, of
   type TBD3, 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.

3.3.3.2.1.

5.2.2.  Interpreting the SR-ERO SRv6-ERO

   The SR-ERO contains a sequence of subobjects.  According to
   [I-D.ietf-spring-segment-routing-policy], each SR-ERO SRv6-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 SRv6-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 SRH onto the SR-ERO
   subobject, but without packets and sending the L flag [I-D.ietf-pce-segment-routing].

   When resulting,
   modified packet to the NAI Type (NT) indicates SRv6, then next hop.

5.3.  RRO Processing

   The syntax checking rules that apply to the SR-RRO SRv6-RRO subobject
   represent are
   identical to those of the SRv6-ERO subobject, except as noted below.

   If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 segment
   SID 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 are absent, it MUST NOT be included.
   The format of SR-RRO subobject is reproduced with consider 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 entire RRO invalid and flags is as per SR-ERO subobject.

   Processing rules
   send a PCErr message with Error-Type = 10 ("Reception of SR-RRO subobject an invalid
   object") and Error-Value = TBD6 ("Both SID and NAI are identical to those of SR-ERO
   subobject. absent in
   SRv6-RRO subobject").

   If a PCE detects that all the subobjects of an RRO are not identical, a mixture of
   SRv6-RRO subobjects and if
   it does not handle such RRO, subobjects of other types, then it MUST send
   a PCErr message with Error-
   Type Error-Type = 10 ("Reception of an invalid
   object") and Error-Value = 10
   ("Non-identical RRO subobjects").

3.4. TBD7 ("RRO mixes SRv6-RRO subobjects with
   other subobject types").

6.  Security Considerations

   The security considerations described in [RFC5440], [RFC8231] and [RFC8231]and
   [RFC8281], [I-D.ietf-pce-segment-routing], are applicable to this
   specification.  No additional security measure is required.

3.5.

7.  IANA Considerations

7.1.  PCEP ERO and RRO subobjects

   This document requests IANA to include (I) bit in flags registry defines a new subobject type for
   SR-ERO the PCEP explicit
   route object (ERO), and SR-RRO sub-objects.  Other changes are defined as:

3.5.1. a new subobject type for the PCEP Objects

3.5.1.1.  ERROR Objects record
   route object (RRO).  The code points for subobject types of these
   objects is maintained in the RSVP parameters registry, under the
   EXPLICIT_ROUTE and ROUTE_RECORD objects.  IANA is requested to
   allocate code-points in the PCEP-ERROR Object
   Error Types and Values RSVP Parameters registry for the following new error-values:

      Error-Type   Meaning
      ----------   -------
      10           Reception each 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
   new subobject types defined in this document.

     Object                Subobject                  Subobject Type Indicators
     --------------------- -------------------------- ------------------
     EXPLICIT_ROUTE        SRv6-ERO (PCEP-specific)     TBD3
     ROUTE_RECORD          SRv6-RRO (PCEP-specific)     TBD4

7.2.  New SRv6-ERO Flag Registry

   IANA is requested to make create a new sub-registry, named "SRv6-ERO Flag
   Field", within the assignment "Path Computation Element Protocol (PCEP) Numbers"
   registry to manage the Flag field of the new code points for SRv6-ERO subobject.  New
   values are to be assigned by Standards Action [RFC8126].  Each bit
   should be tracked with the existing "PCEP TLV following qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

                   Bit     Description            Reference
                   -----   ------------------     --------------
                    0-9      Unassigned
                     10      NAI is absent (F)     This document
                     11      SID is absent (S)     This document

7.3.  PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators

   IANA maintains a sub-registry, named "PATH-SETUP- TYPE-CAPABILITY
   Sub-TLV Type Indicators" Indicators", within the "Path Computation Element
   Protocol (PCEP) Numbers" registry as follows: to manage the type indicator space
   for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV.  IANA is
   requested to make the following assignment:

      Value     Meaning                     Reference
      -----     -------                     ---------
      TBD1      SRv6-PCE-CAPABILITY         This Document

3.5.1.3.  New Path Setup Type

   [RFC8408] defines the PATH-SETUP-TYPE TLV and requests that

7.4.  SRv6 PCE Capability Flags

   IANA
   creates is requested to create a new sub-registry, named "SRv6
   Capability Flag Field", within the "Path Computation Element Protocol
   (PCEP) Numbers" registry to manage the value Flag field of the PATH-SETUP-TYPE TLV's
   PST field. SRv6-PCE-
   CAPABILITY sub-TLV.  New values are to be assigned by Standards
   Action [RFC8126].  Each bit should be tracked with the following
   qualities:

   o  Bit number (counting from bit 0 as the most significant bit)

   o  Capability description

   o  Defining RFC

   The following values are defined in this document:

                    Bit     Description           Reference

                    0-13    Unassigned
                     14     Node or Adjacency     This document
                            Identifier (NAI) is
                            supported (N)
                     15     Unlimited Maximum SID This document
                            Depth (X)

7.5.  New Path Setup Type

   [RFC8408]created a sub-registry within the "Path Computation Element
   Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types".
   IANA is requested to allocate a new code point in the
   PCEP PATH_SETUP_TYPE TLV PST field within this registry,
   as follows:

   Value             Description                  Reference
   -----             -----------                  ---------
   TBD2              SRv6 (SRH) technique              Traffic engineering path is  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.
                     setup using SRv6.

7.6.  ERROR Objects

   IANA is requested to make the
   assignment of the new code points allocate code-points in the afore-mentioned PCEP-ERROR Object
   Error Types and Values registry as
   follows:

      Value     Description                 Reference
      ----- for the following new error-values:

      Error-Type   Meaning
      ----------   -------                     ---------
      TBD3      NAI is
      10           Reception of an invalid object
                   Error-value = TBD5 (Missing
                   PCE-SRv6-CAPABILITY sub-TLV)
                   Error-value = TBD6 (Both SID and NAI are absent
                   in SRv6-RRO subobject)
                   Error-value = TBD7 (RRO mixes SRv6-RRO subobjects
                   with other subobject types)
      19           Invalid Operation
                   Error-value = TBD5 (Attempted SRv6 segment      This Document

4. when the
                   capability was not advertised)

8.  Acknowledgements

   The authors would like to thank Jeff Tentsura for suggestions
   regarding SRv6 MSD Types.

5. Tentsura, Adrian Farrel and
   Khasanov Boris for valuable suggestions.

9.  References

5.1.

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

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <https://www.rfc-editor.org/info/rfc3209>.

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

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

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

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

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

   [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 draft-ietf-6man-segment-routing-header-18 (work in
              progress), February April 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
              extensions-23 (work in progress), December 2018. March 2019.

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

   [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
              dawra-idr-bgpls-srv6-ext-06 (work in progress), 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

   Prejeeth Kaladharan
   RtBrick Inc
   Bangalore, Karnataka
   India

   EMail: prejeeth@rtbrick.com
   Yongqing Zhu
   China Telecom
   109 West Zhongshan Ave, Tianhe District
   Bangalore, Guangzhou
   P.R. China

   EMail: zhuyq.gd@chinatelecom.cn