PCE Working Group                                                M. Negi
Internet-Draft                                             P. Kaladharan
Intended status: Standards Track                                D. Dhody
Expires: September 4, 2018                           Huawei Technologies
                                                            S. Sivabalan
                                                           Cisco Systems
                                                           March 3, 2018


   PCEP Extensions for Segment Routing leveraging the IPv6 data plane
                 draft-negi-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) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).

   It depends only on "segments" that are advertised by Link- State
   Interior Gateway Protocols (IGPs).  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 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 4, 2018               [Page 1]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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 4, 2018.

Copyright Notice

   Copyright (c) 2018 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  . . . . . . . . .   7
       3.3.2.  The RP/SRP Object . . . . . . . . . . . . . . . . . .   9
       3.3.3.  ERO Object  . . . . . . . . . . . . . . . . . . . . .   9
         3.3.3.1.  SR-ERO Subobject  . . . . . . . . . . . . . . . .   9
         3.3.3.2.  ERO Processing  . . . . . . . . . . . . . . . . .  11
       3.3.4.  RRO Object  . . . . . . . . . . . . . . . . . . . . .  12
         3.3.4.1.  SR-RRO Subobject  . . . . . . . . . . . . . . . .  12
     3.4.  Security Considerations . . . . . . . . . . . . . . . . .  13
     3.5.  IANA Considerations . . . . . . . . . . . . . . . . . . .  13
       3.5.1.  PCEP Objects  . . . . . . . . . . . . . . . . . . . .  13
         3.5.1.1.  ERROR Objects . . . . . . . . . . . . . . . . . .  13
         3.5.1.2.  TLV Type Indicators . . . . . . . . . . . . . . .  13
         3.5.1.3.  New Path Setup Type . . . . . . . . . . . . . . .  13



Negi, et al.            Expires September 4, 2018               [Page 2]


Internet-Draft          PCEP Extensions for SRv6              March 2018


     3.6.  The SID Type field  . . . . . . . . . . . . . . . . . . .  14
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     4.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Appendix A.  Contributor  . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   As per [I-D.ietf-spring-segment-routing], 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,
   Locators, 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
   [I-D.ietf-spring-ipv6-use-cases].  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 Path Computation Element Protocol (PCEP) for
   communication between a Path Computation Client (PCC) and a Path



Negi, et al.            Expires September 4, 2018               [Page 3]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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 [I-D.ietf-pce-lsp-setup-type].

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

   PCC:  Path Computation Client.

   PCE:  Path Computation Element.

   PCEP:  Path Computation Element Protocol.

   SR:  Segment Routing.



Negi, et al.            Expires September 4, 2018               [Page 4]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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 should 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 defines new path setup type carried in the
   PATH-SETUP-TYPE TLV for SRv6 path.

   In summary, this document:

   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 TLV
      for SR-TE LSP.




Negi, et al.            Expires September 4, 2018               [Page 5]


Internet-Draft          PCEP Extensions for SRv6              March 2018


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 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.  In other words, a PCEP speaker MUST
   NOT infer whether or not a PCEP message pertains to SRv6 from any
   other object or TLV.

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)
   [I-D.ietf-pce-lsp-setup-type] 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.





Negi, et al.            Expires September 4, 2018               [Page 6]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      max-SL   |  Reserved     |             Flags           |L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


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

   The 4-octet value comprise of -

      max-SL: 1 octet, this field specifies the maximum value of the
      "Segments Left (SL)" in the SRH
      [I-D.ietf-6man-segment-routing-header].

      Reserved: 1 octet, this field MUST be set to 0 on transmission,
      and ignored on receipt.

      Flags: 2 octet, one flag is currently defined in this document.

         L bit: A PCC sets this bit to 1 to indicate that it does not
         impose any limit on SL.

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.





Negi, et al.            Expires September 4, 2018               [Page 7]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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 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 max-ML is not used and MUST be set to zero.  If a PCE
   receives an SRv6-PCE-CAPABILITY sub-TLV with the L flag set to 1 then
   it MUST ignore the max-SL field and MUST assume that the sender can
   impose a SL of any depth.  If a PCC sets the L flag to zero, then it
   sets the max-SL field to the maximum number of SIDs that it can
   impose on a packet.  If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV
   with the L flag and max-SL both set to zero then it MUST assume that
   the PCC is not capable of imposing a SL of any length and hence is
   not SRv6 capable, unless it learns a non-zero max-SL for the PCC
   through some other means.

   Once an SRv6-capable PCEP session is established with a non-zero max-
   SL value, the corresponding PCE MUST NOT send SRv6 paths with a
   number of SIDs exceeding that max-SL value.  If a PCC needs to modify
   the max-SL value, it MUST close the PCEP session and re-establish it
   with the new max-SL value.  If a PCEP session is established with a
   non-zero max-SL value, and the PCC receives an SRv6 path containing
   more SIDs than specified in the max-SL value, 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 max-SL value of zero, then the
   PCC MAY specify an max-SL 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 Max-SL value 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 Max-SL value to zero in an
   outbound message to a PCC.  Similarly, a PCC MUST ignore any max-SL
   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.







Negi, et al.            Expires September 4, 2018               [Page 8]


Internet-Draft          PCEP Extensions for SRv6              March 2018


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 [I-D.ietf-pce-lsp-setup-type].  This
   document defines a new Path Setup Type (PST=TBD2) for SRv6.

3.3.3.  ERO Object

   In order to support SRv6, the SR-ERO subobject is used
   [I-D.ietf-pce-segment-routing].  All other processing rules remains
   the same.

3.3.3.1.  SR-ERO Subobject

   For supporting SRv6, a new SID Type (ST) is defined, the format of
   SR-ERO sub object remains the same as defined in
   [I-D.ietf-pce-segment-routing].

   When the SID Type (ST) 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 MUST be set to zero
   on transit and ignored on receipt.  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    |  ST   |     Flags     |F|S|C|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     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 ST (SID Type) is assigned by IANA as TBD3.

   For SRv6 segments (when ST is TBD3), M and C flag MUST NOT be set.
   The S flag MUST be set and SID field MUST be set to 0.  The F bit
   MUST NOT be set.  The Length is 28.




Negi, et al.            Expires September 4, 2018               [Page 9]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   The SRv6I format 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 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      SRv6 Identifier                          |
   |                         (128-bit)                             |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SRv6ST|         Flags           |       Function Code         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        NAI (variable)                       //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                 Figure 3: SR-ERO Subobject's SRv6I Format

      SRv6 Identifier is the 128 bit IPv6 addresses representing SRv6
      segment.

      SRv6ST is the SRv6 SID 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.

      Function Code is is the 16 bit field representing supported
      functions.  associated with SRv6 SIDs.  [Editor's Note - The
      authors needs to finalize if this functionality be removed for
      now, with a possibility for addition in another extention as the
      [I-D.filsfils-spring-srv6-network-programming] progressses].
      Following function codes are currently defined -

         0: Reserved

         1: End Function

         2: End.DX6 Function

         3: End.DT6 Function

         4: End.X Function






Negi, et al.            Expires September 4, 2018              [Page 10]


Internet-Draft          PCEP Extensions for SRv6              March 2018


      NAI field [I-D.ietf-pce-segment-routing] contains the NAI
      associated with the SRv6 Identifier.  Depending on the value of
      SRv6ST, the NAI can have different formats.

         When SRv6ST 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
         SRv6 Identifier.

         When SRv6ST 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 SRv6ST value is 0, NAI is not included and MUST
         be NULL.

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 ST 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 ST 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 ST value, it would behave as per
   [I-D.ietf-pce-segment-routing].

   [Editor's Note - this is missing from
   [I-D.ietf-pce-segment-routing].]

   If a PCC receives a list of SRv6 segments, and the number of SRv6
   segments exceeds the max-SL 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].





Negi, et al.            Expires September 4, 2018              [Page 11]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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.4.  RRO Object

   In order to support SRv6, the SR-ERO 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 ST (SID Type) is assigned by IANA as TBD3,
   the format of SR-ERO sub object remains the same as defined in
   [I-D.ietf-pce-segment-routing].

   When the SID Type (ST) 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 be set to zero
   on transit and ignored on receipt.  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                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                     SRv6I (variable)                        //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                     Figure 4: SR-RRO Subobject Format

   The description of all fields and flags is as per SR-ERO subobject.

   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-



Negi, et al.            Expires September 4, 2018              [Page 12]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   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

3.5.1.3.  New Path Setup Type

   [I-D.ietf-pce-lsp-setup-type]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:



Negi, et al.            Expires September 4, 2018              [Page 13]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   Value             Description                  Reference
   -----             -----------                  ---------
   TBD2              SRv6 (SRH) technique         This Document



3.6.  The SID Type field

   [Editor's Note - an IANA code point sub registry needs to be setup in
   [I-D.ietf-pce-segment-routing], so that future extensions (like this
   one) can define new ST types (TBD3).]

4.  References

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

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





Negi, et al.            Expires September 4, 2018              [Page 14]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   [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-11 (work in progress),
              November 2017.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.ietf-pce-lsp-setup-type]
              Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying path setup type in PCEP messages",
              draft-ietf-pce-lsp-setup-type-08 (work in progress),
              January 2018.

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

   [I-D.ietf-6man-segment-routing-header]
              Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J.,
              Field, B., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Matsushima, S., Leung, I.,
              Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun,
              D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
              Header (SRH)", draft-ietf-6man-segment-routing-header-08
              (work in progress), January 2018.







Negi, et al.            Expires September 4, 2018              [Page 15]


Internet-Draft          PCEP Extensions for SRv6              March 2018


   [I-D.ietf-spring-ipv6-use-cases]
              Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and
              M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring-
              ipv6-use-cases-12 (work in progress), December 2017.

   [I-D.ietf-isis-segment-routing-extensions]
              Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
              Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
              "IS-IS Extensions for Segment Routing", draft-ietf-isis-
              segment-routing-extensions-15 (work in progress), December
              2017.

   [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
              Psenak, P., Filsfils, C., Previdi, S., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
              Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
              segment-routing-extensions-11 (work in progress), January
              2018.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
              Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
              Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
              Camarillo, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-03 (work in progress),
              December 2017.






















Negi, et al.            Expires September 4, 2018              [Page 16]


Internet-Draft          PCEP Extensions for SRv6              March 2018


Appendix A.  Contributor

   The following persons contributed to this document:

   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


   Prejeeth Kaladharan
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: prejeeth.k@huawei.com


   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore, Karnataka  560066
   India

   EMail: dhruv.ietf@gmail.com


   Siva Sivabalan
   Cisco Systems

   EMail: msiva@cisco.com






Negi, et al.            Expires September 4, 2018              [Page 17]