[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

PCE Working Group                                                  C. Li
Internet-Draft                                                   M. Chen
Intended status: Standards Track                                 J. Dong
Expires: February 22, 2019                                         Z. Li
                                                                D. Dhody
                                                     Huawei Technologies
                                                         August 21, 2018


  Path Computation Element Communication Protocol (PCEP) Extension for
              Path Identification in Segment Routing (SR)
                    draft-li-pce-sr-path-segment-01

Abstract

   The Path Computation Element (PCE) provides path computation
   functions in support of traffic engineering in Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) networks.

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

   Path identification is needed for several use cases such as
   performance measurement in Segment Routing (SR) network.  This
   document specifies extensions to the Path Computation Element
   Protocol (PCEP) to support requesting, replying, reporting and
   updating the path identifier between PCEP speakers.

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




Li, et al.              Expires February 22, 2019               [Page 1]


Internet-Draft               Path ID in PCEP                 August 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 February 22, 2019.

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 Path ID Extensions in PCEP  . . . . . . . . . . .   4
   4.  Objects and TLVs  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  The OPEN Object . . . . . . . . . . . . . . . . . . . . .   5
       4.1.1.  The SR PCE Capability sub-TLV . . . . . . . . . . . .   5
       4.1.2.  The SRv6 PCE Capability sub-TLV . . . . . . . . . . .   5
       4.1.3.  PCECC-CAPABILITY sub-TLV  . . . . . . . . . . . . . .   6
     4.2.  LSP Object  . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Path ID TLV . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  FEC Object  . . . . . . . . . . . . . . . . . . . . . . .   9
     4.4.  CCI Object  . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  PCC Allocated Path ID . . . . . . . . . . . . . . . . . .  11
       5.1.1.  Egress PCC Allocated Path ID  . . . . . . . . . . . .  11
       5.1.2.  Ingress PCC Allocated Path ID . . . . . . . . . . . .  15
     5.2.  PCE Allocated Path ID . . . . . . . . . . . . . . . . . .  16
       5.2.1.  PCE Controlled ID Spaces Advertisement  . . . . . . .  16
       5.2.2.  Ingress PCC request Path ID to PCE  . . . . . . . . .  16
       5.2.3.  PCE allocated Path ID on its own  . . . . . . . . . .  17
     5.3.  Two Label Solution  . . . . . . . . . . . . . . . . . . .  18



Li, et al.              Expires February 22, 2019               [Page 2]


Internet-Draft               Path ID in PCEP                 August 2018


   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  19
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  19
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

1.  Introduction

   [RFC5440] describes the Path Computation Element (PCE) Communication
   Protocol (PCEP).  PCEP enables the communication between a Path
   Computation Client (PCC) and a PCE, or between PCE and PCE, for the
   purpose of computation of Multiprotocol Label Switching (MPLS) as
   well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched
   Path (TE LSP) characteristics.

   [RFC8231] specifies a set of extensions to PCEP to enable stateful
   control of TE LSPs within and across PCEP sessions in compliance with
   [RFC4657].  It includes mechanisms to effect LSP State
   Synchronization between PCCs and PCEs, delegation of control over
   LSPs to PCEs, and PCE control of timing and sequence of path
   computations within and across PCEP sessions.  The model of operation
   where LSPs are initiated from the PCE is described in [RFC8281].

   [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the
   procedures and PCEP protocol extensions for using the PCE as the
   central controller for static LSPs, where LSPs can be provisioned as
   explicit label instructions at each hop on the end-to-end path.

   Segment routing (SR) [I-D.ietf-spring-segment-routing] leverages the
   source routing and tunneling paradigms and supports steering packets
   into an explicit forwarding path at the ingress node.

   An SR path needs to be identified in some use cases such as
   performance measurement.  For identifying an SR path,
   [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is
   referred to as Path Segment.

   [I-D.ietf-pce-segment-routing] specifies extensions to the Path
   Computation Element Protocol (PCEP) [RFC5440] for SR networks, that
   allow a stateful PCE to compute and initiate SR-TE paths, as well as
   a PCC to request, report or delegate SR paths.
   [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR for
   IPv6 data plane.

   [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the
   procedures and PCEP protocol extensions when a PCE-based controller



Li, et al.              Expires February 22, 2019               [Page 3]


Internet-Draft               Path ID in PCEP                 August 2018


   is also responsible for configuring the forwarding actions on the
   routers (SR SID distribution in this case), in addition to computing
   the paths for packet flows in a segment routing network and telling
   the edge routers what instructions to attach to packets as they enter
   the network.

   This document specifies a mechanism to carry the SR path
   identification information in PCEP messages [RFC5440] [RFC8231]
   [RFC8281].  The path ID can be a path segment in SR-MPLS
   [I-D.cheng-spring-mpls-path-segment], or a path ID in SRv6
   [I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can
   identify the SR path.  This document also extends the PCECC-SR
   mechanism to inform the path ID to the egress PCC.

2.  Terminology

   This memo makes use of the terms defined in [RFC4655],
   [I-D.ietf-pce-segment-routing], and
   [I-D.ietf-spring-segment-routing].

3.  Overview of Path ID Extensions in PCEP

   This document specifies a mechanism of encoding (and allocating) path
   ID (path segment in case of MPLS, path ID in case of IPv6, etc) in
   PCEP extensions.  For supporting path ID in PCEP, several TLVs and
   flags are defined.  The formats of the objects and TLVs are described
   in Section 4.  The procedures of path ID allocation are described in
   Section 5.

   There are various modes of operations, such as -

   o  The path ID can be allocated by Egress PCC.  The PCE should
      request the Path ID from Egress PCC.

   o  The path ID can be allocated by Ingress PCC itself and informed to
      the PCE.  The PCE can then inform the egress PCC.

   o  Ingress PCC can also request PCE to allocate the path ID, in this
      case, the PCE would allocate and inform the assigned path ID to
      the ingress/egress PCC using PCEP messages.

   o  The PCE can allocate a path ID on its own accord and inform the
      ingress/egress PCC , useful for PCE-initiated LSPs.

   The path information to the ingress PCC and PCE is exchanged via an
   extension to [I-D.ietf-pce-segment-routing] and
   [I-D.negi-pce-segment-routing-ipv6].  The path ID information to the




Li, et al.              Expires February 22, 2019               [Page 4]


Internet-Draft               Path ID in PCEP                 August 2018


   egress PCC is informed via an extension to the PCECC-SR procedures
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].

   For the PCE to allocate a path ID, the PCE SHOULD be aware of the
   path ID space from the PCCs.  This is done via mechanism as described
   in [I-D.li-pce-controlled-id-space].  Otherwise, the PCE should
   request the egress PCC of Path IDs.

4.  Objects and TLVs

4.1.  The OPEN Object

4.1.1.  The SR PCE Capability sub-TLV

   [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST)
   and SR-PCE-CAPABILITY sub-TLV for SR.  PCEP speakers use this sub-TLV
   to exchange information about their SR capability.  The TLV includes
   a Flags field and one bit (L-flag) was allocated in
   [I-D.ietf-pce-segment-routing].

   This document adds an additional flag for path ID allocation, as
   follows -

      P (Path Identification bit): A PCEP speaker sets this flag to 1 to
      indicate that it has the capability to encode SR path
      identification (path segment, as per
      [I-D.cheng-spring-mpls-path-segment]).

    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=26            |            Length=4           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Reserved              |   Flags |P|N|L|      MSD      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 1: P-flag in SR-PCE-CAPABILITY TLV

   The figure is included for the ease of the reader and can be removed
   at the time of publication.

4.1.2.  The SRv6 PCE Capability sub-TLV

   [I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type
   (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6.  PCEP speakers use
   this sub-TLV to exchange information about their SRv6 capability.
   The TLV includes a Flags field and one bit (L-flag) was allocated in
   [I-D.negi-pce-segment-routing-ipv6].



Li, et al.              Expires February 22, 2019               [Page 5]


Internet-Draft               Path ID in PCEP                 August 2018


   This document adds an additional flag for path ID allocation, as
   follows -

      P (Path Identification bit): A PCEP speaker sets this flag to 1 to
      indicate that it has the capability to encode SRv6 path
      identification.

    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         |P|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV

   The figure is included for the ease of the reader and can be removed
   at the time of publication.

4.1.3.  PCECC-CAPABILITY sub-TLV

   The PCECC Capability as per
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] should also be
   advertised on the egress PCEP session, along with the SR sub-TLVs.
   This is needed to ensure that the PCE can use the PCECC objects/
   mechanism to request/inform the egress PCC of the path ID as
   described in this document.

4.2.  LSP Object

   The LSP Object is defined in Section 7.3 of [RFC8231].  This document
   adds the following flags to the LSP Object:

      P (Path Identification Allocation bit): If the bit is set to 1, it
      indicates that the path identifier needs to be allocated by the
      PCE for this LSP.  A PCC would set this bit to 1 to request for
      allocation of path identifier by the PCE in the PCReq or PCRpt
      message.  A PCE would also set this bit to 1 to indicate that the
      path identifier is allocated by PCE and encoded in the PCRep,
      PCUpd or PCInitiate message (the PATH-ID TLV MUST be present in
      LSP object).  Further, a PCE would set this bit to 0 to indicate
      that the path identifier should be allocated by the PCC as
      described in Section 5.1.1.







Li, et al.              Expires February 22, 2019               [Page 6]


Internet-Draft               Path ID in PCEP                 August 2018


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                PLSP-ID                |  Flag |P|  O  |A|R|S|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                        TLVs                                 //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: P-flag in LSP Object

   The figure is included for the ease of the reader and can be removed
   at the time of publication.

4.2.1.  Path ID TLV

   The PATH-ID TLV is an optional TLV for use in the LSP Object for path
   ID allocation.  The type of this TLV is to be allocated by IANA.  The
   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Type              |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       IDT     |             Flags                         |E|L|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Path ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                     Figure 4: The PATH-ID TLV Format

   The type (16-bit) of the TLV is TBA (to be allocated by IANA).  The
   length (16-bit) has a fixed value of 8 octets.  The value contains
   the following fields:

      IDT (The ID type - 8 bits): The IDT field specifies the type of
      the Path ID field, which carries a Path ID corresponding to the SR
      path.

      *  0: MPLS Path Segment, which is an MPLS label as defined in
         [I-D.cheng-spring-mpls-path-segment].  The PST type MUST be set
         to SR (MPLS).






Li, et al.              Expires February 22, 2019               [Page 7]


Internet-Draft               Path ID in PCEP                 August 2018


      *  1: SRv6 Path ID, which is a 4-octet integer as defined in
         [I-D.li-spring-passive-pm-for-srv6-np].  The PST type MUST be
         set to SRv6.

      Flags (24 bits): Two flags are currently defined:

      *  L-Bit (Local/Global - 1 bit): If set, then the Path ID carried
         by the PATH-ID TLV has local significance.  If not set, then
         the Path ID carried by this TLV has global significance (i.e.
         Path ID is global within an SR domain).

      *  E-bit (Egress/Ingress - 1 bit): If set, then the Path ID
         carried by the PATH-ID TLV is allocated from the Egress Path ID
         space.  If not set, then the Path ID carried by this TLV is
         allocated from the Ingress Path ID space.

      *  The unassigned bits MUST be set to 0 and MUST be ignored at
         receipt.

      Path ID: The path ID of an SR path.  The path ID type is indicated
      by the ID Type field.  It can be a path segment
      [I-D.cheng-spring-mpls-path-segment] in MPLS label format.  Or it
      can be a 4 octets integer ID as defined in
      [I-D.li-spring-passive-pm-for-srv6-np] or other IDs that can
      identify a path.

   Only one instance of PATH-ID TLV is processed, if more than one PATH-
   ID TLV is included, the first one is processed and others MUST be
   ignored.

   When the path ID allocation is enable, a PATH-ID TLV should be
   included in the LSP object.

   If the label space is maintained by PCC itself, and the path ID is
   allocated by Egress PCC, then the PCE should request the Path ID from
   Egress PCC as described in Section 5.1.1.  In this case, the PCE
   should send a PCUpdate or PCInitiate message to the egress PCC to
   request the path ID.  The P-flag in LSP should be unset in this case.

   If the path ID is allocated by the ingress node, a PATH-ID TLV MUST
   be included in a LSP object (with E-bit unset) in the PCEP message
   from PCC.  The L-flag is set if the path ID has local significance.
   In this case, the P flag in LSP object is set to 0.

   If the PCC requests the path ID to be allocated by the PCE, P flag in
   LSP object is set to 1 and Path ID TLV MAY be skipped.  After the PCE
   has allocated a path ID, it MUST include the PATH-ID TLV in a LSP




Li, et al.              Expires February 22, 2019               [Page 8]


Internet-Draft               Path ID in PCEP                 August 2018


   object, the E-bit is set by PCE based on the path ID space from which
   the allocation is made.

   If the PCE allocated the path ID on its own accord, a PATH-ID TLV
   MUST be included in a LSP object, the E-bit is set by PCE based on
   the path ID space from which the allocation is made.

4.3.  FEC Object

   The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is
   used to specify the FEC information and MAY be carried within
   PCInitiate or PCRpt message for the PCECC-SR operations.  The PCE
   MUST inform the Path Identification information to the Egress PCC.
   To do this, this document extends the procedures of
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC
   object type for Path.

   FEC Object-Type is TBD 'Path'.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                           TLV(s)                            //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 5: The path FEC object Format

   One or more following TLV(s) are allowed in the 'path' FEC object -

   o  SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human-
      readable string that identifies an LSP in the network.

   o  LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for
      SR, but could be used to encode the source, destination and other
      identification information for the path.

   o  SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique
      identifier for the PCEP speaker, it is used to identify the
      Ingress PCC.

   Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be
   included.  SPEAKER-ENTITY-ID TLV is optional.  Only one instance of
   each TLV is processed, if more than one TLV of each type is included,
   the first one is processed and others MUST be ignored.





Li, et al.              Expires February 22, 2019               [Page 9]


Internet-Draft               Path ID in PCEP                 August 2018


4.4.  CCI Object

   The Central Control Instructions (CCI) Object is used by the PCE to
   specify the forwarding instructions is defined in
   [I-D.zhao-pce-pcep-extension-for-pce-controller].  Further
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object
   type for SR.

   The Path ID information is encoded directly in the CCI SR object.
   The Path ID TLV as described in the Section 4.2.1, MUST also be
   included in the CCI SR object as the TLV includes additional
   information regarding the path identifier.

   This document adds the following flags to the CCI Object:

   o  C (PCC Allocation bit): If the bit is set to 1, it indicates that
      the allocation needs to be done by the PCC for this central
      controller instruction.  A PCE set this bit to request the PCC to
      make an allocation from its SR label/ID space.  A PCC would set
      this bit to indicate that it has allocated the CC-ID and report it
      to the PCE.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            CC-ID                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MT-ID    |    Algorithm  |        Flags      |C|N|E|V|L|O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                  SID/Label/Index (variable)                 //
   +---------------------------------------------------------------+
   |                                                               |
   //                        Optional TLV                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 6: The CCI object for SR

   (Editor's Note - An update is planned for
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision
   detailing this procedure, and the above text might move there.)

5.  Operations

   The path ID allocation and encoding is as per the stateful PCE
   operations for segment routing.  The procedures are as per the
   corresponding extensions defined in [I-D.ietf-pce-segment-routing]
   and [I-D.negi-pce-segment-routing-ipv6] (which are further based on



Li, et al.              Expires February 22, 2019              [Page 10]


Internet-Draft               Path ID in PCEP                 August 2018


   [RFC8231] and [RFC8281]).  The additional operations for path
   identification are defined in this section.

   To notify (or request) the path ID to the Egress PCC, the procedures
   are as per the PCECC-SR
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on
   [I-D.zhao-pce-pcep-extension-for-pce-controller]).  The additional
   operations are defined in this section.

5.1.  PCC Allocated Path ID

5.1.1.  Egress PCC Allocated Path ID

   As defined in [I-D.cheng-spring-mpls-path-segment], a path segment/ID
   can be allocated by the egress PCC.  In this case, the ID/label space
   may be maintained on the PCC itself.

   On receiving a stateful path computation request with path ID
   allocation request from an ingress PCC, or by initiating or updating
   an LSP with path ID actively, a PCE can request the egress PCC to
   allocate a path ID.  This is needed if the PCE does not control the
   path IDs for the egress PCC or the ID/label space is maintained by
   the egress PCC itself.

   The mechanism of Path ID request and reply may be achieved by using
   PCInitiate and PCUpd message as described in this section.

5.1.1.1.  Using CCI and FEC objects (PCECC)

   The PCE can request the egress to allocate the path ID using the
   PCInitiate message as described in
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].  The C flag in the
   CCI object is set to 1 and the CC-ID is set to a special value of
   0x0000 to indicate that the allocation needs to be done by the PCC.
   The PATH-ID TLV is also be included in CCI object along with the FEC
   object identifying the SR-Path.  The egress PCC would allocate the
   path identification and would report to the PCE using the PCRpt
   message as described in
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] with the allocated
   path identification in the CC-ID field as well as in the PATH-ID TLV.

   (Editor's Note - An update is planned for
   [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision
   detailing this procedure)

   If the value of CC-ID/Path-ID is 0 and the C flag is set, it
   indicates that the PCE is requesting a path ID for this LSP.  If the
   CC-ID/Path ID is 'n' and the C flag is set in the CCI object, it



Li, et al.              Expires February 22, 2019              [Page 11]


Internet-Draft               Path ID in PCEP                 August 2018


   indicates that the PCE requests a specific value 'n' of path ID.  If
   the path ID is allocated successfully, the egress PCC should report
   the path ID via PCRpt message with the CCI object along with the
   PATH-ID TLV.  Else, it MUST send a PCErr message with Error-Type =
   TBD ("Path SID failure") and Error Value = TBD ("Invalid SID").  If
   the value of path ID in CCI object is valid, but the PCC is unable to
   allocate the path ID, it MUST send a PCErr message with Error-Type =
   TBD ("Path label/SID failure") and Error Value = TBD ("Unable to
   allocate the specified label/SID").

   Once the PCE receives the PCRpt message with the CCI object, it can
   obtain the Path ID information from the egress PCC and then update
   the path with path ID or reply to the ingress PCC, the path
   information with path ID.

   If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt
   message to the PCE.  In case of error, as described in
   [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to
   the PCE.  The PCE MUST request the withdraw of the path ID allocation
   by sending a PCInitiate message to remove the central controller
   instruction as per [I-D.zhao-pce-pcep-extension-pce-controller-sr].
   When the LSP is deleted or the path ID is removed, the PCE should
   synchronize with the egress PCC.

   If the egress PCC wishes to withdraw or modify a previously reported
   path ID value, it MUST send a PCRpt message without any PATH-ID TLV
   or with the PATH-ID TLV containing the new path ID respectively in
   the CCI object.  The PCE would further trigger the removal of the
   central controller instruction as per
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].

   If a PCE wishes to modify a previously requested path ID value, it
   MUST send a new PCInitiate message with an allocation request CC-ID/
   PATH-ID TLV containing the new path ID value and C flag is set.  The
   PCE should trigger the removal of the older path ID next as per
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].















Li, et al.              Expires February 22, 2019              [Page 12]


Internet-Draft               Path ID in PCEP                 August 2018


               Ingress                                    Egress
               +-+-+                +-+-+                 +-+-+
               |PCC|                |PCE|                 |PCC|
               +-+-+                +-+-+                 +-+-+
   1) LSP State  | ----  PCRpt ---->  |                     |
      Delegate   |     Delegate=1     |                     |
                 |     P=1            |2) PCE update        |
                 |                    |   the LSP-DB and    |
                 |                    |   request Path ID   |
                 |                    |                     |
                 |                    | --- PCInitiate ---> | Egress
                 |                    |      CC-ID=0        | allocates
                 |                    |      FEC=Path       | a Path-ID
                 |                    |                     | from its
                 |                    | <----- PCRpt ------ | space
                 |                    |       CC-ID=        |
                 |                    |       Path ID       |
                 |                    |                     |
                 |<----  PCUpd ----   |3)Paths update with  |
                 |     PATH-ID TLV    |  Path ID            |
                 |                    |                     |
   4) LSP State  | -----  PCRpt --->  |                     |
      Report     |                    |                     |
                 |                    |                     |

                  Figure 7: Egress PCC Allocated Path ID

5.1.1.2.  Using LSP objects (PCEP-SR)

   The PATH-ID TLV MUST be included in an LSP object in the PCInitiate
   message sent from the PCE to the egress to request path
   identification allocation by the egress PCC.  The P flag in LSP
   object MUST be set to 0.  This PCInitiate message to egress PCC would
   be the similar to the one sent to ingress PCC as per
   [I-D.ietf-pce-segment-routing], but the egress PCC would only
   allocate the path identification and would not trigger the
   initiation/update operation.

   If the value of path ID is 0 it indicates that the PCE is requesting
   a path ID for this LSP.  If the Path ID is 'n' and the P flag is
   unset in the LSP object, it indicates that the PCE requests a
   specific value 'n' of path ID.  If the path ID is allocated
   successfully, the egress PCC should report the path ID via PCRpt
   message with PATH-ID TLV in LSP object.  Else, it MUST send a PCErr
   message with Error-Type = TBD ("Path SID failure") and Error Value =
   TBD ("Invalid SID").  If the value of path ID is valid, but the PCC
   is unable to allocate the path ID, it MUST send a PCErr message with




Li, et al.              Expires February 22, 2019              [Page 13]


Internet-Draft               Path ID in PCEP                 August 2018


   Error-Type = TBD ("Path label/SID failure") and Error Value = TBD
   ("Unable to allocate the specified label/SID").

   Once the PCE receives the PCRpt message, it can obtain the Path ID
   information from the egress PCC and then update the path with path ID
   or reply to the ingress PCC, the path information with path ID.

   If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt
   message to the PCE.  In case of error, as described in
   [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to
   the PCE.  The PCE MUST request the withdraw of the path ID allocation
   by sending a PCUpd message to remove the LSP and associated path ID
   by setting the R flag in the SRP object.  When the LSP is deleted or
   the path ID is removed, the PCE should send a PCUpd message to
   synchronize with the egress PCC.

   If the egress PCC wishes to withdraw or modify a previously reported
   path ID value, it MUST send a PCRpt message without any PATH-ID TLV
   or with the PATH-ID TLV containing the new path ID respectively.

   If a PCE wishes to modify a previously requested path ID value, it
   MUST send a PCUpd message with PATH-ID TLV containing the new path ID
   value and P flag is LSP object would be unset.  Absence of the PATH-
   ID TLV in PCUpd message means that the PCE wishes to withdraw the
   path ID.

   If a PCC receives a valid path ID value from a PCE which is different
   than the current path ID, it MUST try to allocate the new value.  If
   the new path ID is successfully allocated, the PCC MUST report the
   new value to the PCE.  Otherwise, it MUST send a PCErr message with
   Error-Type = TBD ("Path label/SID failure") and Error Value = TBD
   ("Unable to allocate the specified label/SID").



















Li, et al.              Expires February 22, 2019              [Page 14]


Internet-Draft               Path ID in PCEP                 August 2018


               Ingress                                    Egress
               +-+-+                +-+-+                 +-+-+
               |PCC|                |PCE|                 |PCC|
               +-+-+                +-+-+                 +-+-+
   1) LSP State  | ----  PCRpt ---->  |                     |
      Delegate   |     Delegate=1     |                     |
                 |     P=1            |2) PCE update        |
                 |                    |   the LSP-DB and    |
                 |                    |   request Path ID   |
                 |                    |                     |
                 |                    | --- PCInitiate ---> | Egress
                 |                    |      PATH-ID TLV in | allocates
                 |                    |      LSP Object     | a Path-ID
                 |                    |                     | from its
                 |                    | <----- PCRpt ------ | space
                 |                    |       Path ID       |
                 |                    |                     |
                 |<----  PCUpd ----   |3)Paths update with  |
                 |     PATH-ID TLV    |  Path ID            |
                 |                    |                     |
   4) LSP State  | -----  PCRpt --->  |                     |
      Report     |                    |                     |
                 |                    |                     |


                  Figure 8: Egress PCC Allocated Path ID

5.1.2.  Ingress PCC Allocated Path ID

   The Ingress PCC could allocate the Path ID and inform the PCE via the
   PCRpt message as per [RFC8231].  The PATH-ID TLV MUST be included in
   a LSP object in the PCEP message from PCC.  The P flag in LSP object
   is set to 0.  On receiving this report, the PCE updates the
   information in its database.  The active PCE (where the LSP is
   delegated) further informs the egress about the path ID allocated by
   the PCC using the PCInitiate message as described in
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].














Li, et al.              Expires February 22, 2019              [Page 15]


Internet-Draft               Path ID in PCEP                 August 2018


                     Ingress                                    Egress
                     +-+-+                +-+-+                 +-+-+
                     |PCC|                |PCE|                 |PCC|
                     +-+-+                +-+-+                 +-+-+
   1) LSP State        | ----  PCRpt ---->  |                     |
      Delegate and     |     Delegate=1     |                     |
      Inform the       |     PATH-ID TLV    |2) PCE update        |
      Path ID alloc    |                    |   the LSP-DB        |
      by PCC           |                    |                     |
                       |3) PCE informs the  | --- PCInitiate ---> |
                       |   Path ID to Egress|     FEC=Path        |
                       |                    |                     |
                       |                    | <-------- PCRpt --- |
                       |                    |                     |


                  Figure 9: Ingress PCC Allocated Path ID

5.2.  PCE Allocated Path ID

5.2.1.  PCE Controlled ID Spaces Advertisement

   For allocating the path IDs to SR paths by the PCEs, the PCE
   controlled ID Spaces MUST be known at PCEs via configurations or any
   other mechanism.  The PCE controlled ID spaces MAY be advertised as
   described in [I-D.li-pce-controlled-id-space].

5.2.2.  Ingress PCC request Path ID to PCE

   The ingress PCC could request the path ID to be allocated by the PCE
   via PCRpt message as per [RFC8231].  The delegate flag (D-flag) MUST
   also be set for this LSP.  The PATH-ID TLV MAY be included with Path
   ID set to 0x0000.  The active PCE would allocated the path ID as per
   the PATH-ID flags and in case PATH-ID is not included, the PCE MUST
   act based on the local policy.  The PCE would further respond to
   Ingress PCC with PCUpd message as per [RFC8231] and MUST include the
   PATH-ID TLV in a LSP object.  The PCE would further inform the egress
   PCC about the path ID allocated by the PCE using the PCInitiate
   message as described in
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].











Li, et al.              Expires February 22, 2019              [Page 16]


Internet-Draft               Path ID in PCEP                 August 2018


                     Ingress                                    Egress
                     +-+-+                +-+-+                 +-+-+
                     |PCC|                |PCE|                 |PCC|
                     +-+-+                +-+-+                 +-+-+
   1) LSP State        | ----  PCRpt ---->  |                     |
      Delegate         |     Delegate=1     |                     |
                       |     P=1            |2) PCE update        |
                       |                    |   the LSP-DB and    |
                       |                    |   allocate Path ID  |
                       |<----  PCUpd ----   |3)Paths update with  |
                       |     PATH-ID TLV    |  Path ID            |
                       |                    |                     |
   4) LSP State Report | -----  PCRpt --->  |                     |
                       |                    |                     |
                       |5) PCE informs the  | --- PCInitiate ---> |
                       |   Path ID to Egress|     FEC=Path        |
                       |                    |                     |
                       |                    | <-------- PCRpt --- |
                       |                    |                     |


               Figure 10: Ingress PCC request Path ID to PCE

5.2.3.  PCE allocated Path ID on its own

   The PCE could allocate the path ID on its own accord for a PCE-
   Initiated (or delegated LSP).  The allocated path ID needs to be
   informed to the Ingress and Egress PCC.  The PCE would use the
   PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the
   Ingress PCC and MUST include the PATH-ID TLV in the LSP object.  The
   PCE would further inform the egress PCC about the path ID allocated
   by the PCE using the PCInitiate message as described in
   [I-D.zhao-pce-pcep-extension-pce-controller-sr].


















Li, et al.              Expires February 22, 2019              [Page 17]


Internet-Draft               Path ID in PCEP                 August 2018


                     Ingress                                    Egress
                     +-+-+                +-+-+                 +-+-+
                     |PCC|                |PCE|                 |PCC|
                     +-+-+                +-+-+                 +-+-+
                       |                    |                     |
                       | <--PCInitiate---   |1)Initiate LSP with  |
                       |    PATH-ID TLV     |  Path ID            |
                       |                    |                     |
    2)LSP delegation   |---PCRpt, D=1--->   | (Confirm)           |
                       |                    |                     |
                       |3) PCE informs the  | --- PCInitiate ---> |
                       |   Path ID to Egress|     FEC=Path        |
                       |                    |                     |
                       |                    | <-------- PCRpt --- |
                       |                    |                     |


                Figure 11: PCE allocated Path ID on its own

5.3.  Two Label Solution

   [I-D.cheng-spring-mpls-path-segment] describe a Path Segment to
   uniquely identify an SR path in a specific context. (e.g., in the
   context of the egress node or ingress node of an SR path, or within
   an SR domain).  It further describes two solution based on 'one
   label' or 'two labels' solution.  For the latter, two segments
   (Source segment and Path segment) are used to identify an SR path
   where the source segment is a global node segment which can uniquely
   identify a node within the SR domain (it is NOT used for forwarding
   and indicates that a Path segment immediately follows).  The
   combination of Source segment and Path segment uniquely identify an
   SR Path with an SR domain.

   The procedure described in this document allocates and encode the
   Path Segment only.  It is expected that the Egress PCC is aware of
   the Source segment by some other procedures.  These procedures could
   be IGP, PCECC-SR, or some other mechanisms.

6.  IANA Considerations

   TBA

7.  Security Considerations

   TBA






Li, et al.              Expires February 22, 2019              [Page 18]


Internet-Draft               Path ID in PCEP                 August 2018


8.  Acknowledgments

9.  References

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

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

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

   [RFC8232]  Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
              and D. Dhody, "Optimizations of Label Switched Path State
              Synchronization Procedures for a Stateful PCE", RFC 8232,
              DOI 10.17487/RFC8232, September 2017,
              <https://www.rfc-editor.org/info/rfc8232>.

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

   [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-12 (work in progress), June
              2018.








Li, et al.              Expires February 22, 2019              [Page 19]


Internet-Draft               Path ID in PCEP                 August 2018


   [I-D.negi-pce-segment-routing-ipv6]
              Negi, M., Kaladharan, P., Dhody, D., and S. Sivabalan,
              "PCEP Extensions for Segment Routing leveraging the IPv6
              data plane", draft-negi-pce-segment-routing-ipv6-02 (work
              in progress), June 2018.

   [I-D.li-pce-controlled-id-space]
              Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "PCE
              Controlled ID Space", draft-li-pce-controlled-id-space-00
              (work in progress), June 2018.

   [I-D.zhao-pce-pcep-extension-pce-controller-sr]
              Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
              and C. Zhou, "PCEP Procedures and Protocol Extensions for
              Using PCE as a Central Controller (PCECC) of SR-LSPs",
              draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work
              in progress), June 2018.

   [I-D.zhao-pce-pcep-extension-for-pce-controller]
              Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A.,
              and C. Zhou, "PCEP Procedures and Protocol Extensions for
              Using PCE as a Central Controller (PCECC) of LSPs", draft-
              zhao-pce-pcep-extension-for-pce-controller-08 (work in
              progress), June 2018.

9.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

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

   [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.cheng-spring-mpls-path-segment]
              Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., Zhan,
              S., and R. Gandhi, "Path Segment in MPLS Based Segment
              Routing Network", draft-cheng-spring-mpls-path-segment-02
              (work in progress), July 2018.



Li, et al.              Expires February 22, 2019              [Page 20]


Internet-Draft               Path ID in PCEP                 August 2018


   [I-D.li-spring-passive-pm-for-srv6-np]
              Li, C. and M. Chen, "Passive Performance Measurement for
              SRv6 Network Programming", draft-li-spring-passive-pm-for-
              srv6-np-00 (work in progress), March 2018.

Authors' Addresses

   Cheng Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: chengli13@huawei.com


   Mach(Guoyi) Chen
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: Mach.chen@huawei.com


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: jie.dong@huawei.com


   Zhenbin Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing  100095
   China

   Email: lizhenbin@huawei.com










Li, et al.              Expires February 22, 2019              [Page 21]


Internet-Draft               Path ID in PCEP                 August 2018


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

   Email: dhruv.ietf@gmail.com












































Li, et al.              Expires February 22, 2019              [Page 22]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/