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

Versions: 00 01 02 03 04

PCE Working Group                                                  Z. Li
Internet-Draft                                                   S. Peng
Intended status: Standards Track                                 X. Geng
Expires: January 14, 2021                            Huawei Technologies
                                                                 M. Negi
                                                           RtBrick India
                                                           July 13, 2020


   PCEP Procedures and Protocol Extensions for Using PCE as a Central
                    Controller (PCECC) for P2MP LSPs
         draft-dhody-pce-pcep-extension-pce-controller-p2mp-04

Abstract

   The Path Computation Element (PCE) is a core component of Software-
   Defined Networking (SDN) systems.  It can compute optimal paths for
   traffic across a network and can also update the paths to reflect
   changes in the network or traffic demands.

   The PCE has been identified as an appropriate technology for the
   determination of the paths of point- to-multipoint (P2MP) TE Label
   Switched Paths (LSPs).

   PCE was developed to derive paths for MPLS P2MP LSPs, which are
   supplied to the head end (root) of the LSP using PCEP.  PCEP has been
   proposed as a control protocol to allow the PCE to be fully enabled
   as a central controller.

   A PCE-based central controller (PCECC) can simplify the processing of
   a distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.  Thus, the P2MP LSP can
   be calculated/setup/initiated and the label forwarding entries can
   also be downloaded through a centralized PCE server to each network
   devices along the P2MP path while leveraging the existing PCE
   technologies as much as possible.

   This document specifies the procedures and PCEP protocol extensions
   for using the PCE as the central controller for P2MP TE LSP.

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 January 14, 2021                [Page 1]


Internet-Draft                    PCECC                        July 2020


   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 January 14, 2021.

Copyright Notice

   Copyright (c) 2020 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
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   5
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  Basic PCECC Mode  . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Procedures for Using the PCE as the Central Controller
       (PCECC) for P2MP  . . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Stateful PCE Model  . . . . . . . . . . . . . . . . . . .   5
     4.2.  PCECC Capability Advertisement  . . . . . . . . . . . . .   6
     4.3.  LSP Operations  . . . . . . . . . . . . . . . . . . . . .   6
       4.3.1.  Basic PCECC LSP Setup . . . . . . . . . . . . . . . .   6
       4.3.2.  Central Control Instructions  . . . . . . . . . . . .   7
         4.3.2.1.  Label Download CCI  . . . . . . . . . . . . . . .   7
         4.3.2.2.  Label Cleanup CCI . . . . . . . . . . . . . . . .   8
       4.3.3.  PCE Initiated PCECC LSP . . . . . . . . . . . . . . .   9
       4.3.4.  PCECC LSP Update  . . . . . . . . . . . . . . . . . .   9
       4.3.5.  Re-Delegation and Cleanup . . . . . . . . . . . . . .   9
       4.3.6.  Synchronization of Central Controllers Instructions .   9
       4.3.7.  PCECC LSP State Report  . . . . . . . . . . . . . . .   9
   5.  PCEP Objects  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  OPEN Object . . . . . . . . . . . . . . . . . . . . . . .  10
       5.1.1.  PCECC Capability sub-TLV  . . . . . . . . . . . . . .  10



Li, et al.              Expires January 14, 2021                [Page 2]


Internet-Draft                    PCECC                        July 2020


     5.2.  PATH-SETUP-TYPE TLV . . . . . . . . . . . . . . . . . . .  10
     5.3.  CCI Object  . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Manageability Considerations  . . . . . . . . . . . . . . . .  11
     7.1.  Control of Function and Policy  . . . . . . . . . . . . .  11
     7.2.  Information and Data Models . . . . . . . . . . . . . . .  11
     7.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  11
     7.4.  Verify Correct Operations . . . . . . . . . . . . . . . .  11
     7.5.  Requirements On Other Protocols . . . . . . . . . . . . .  11
     7.6.  Impact On Network Operations  . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  PCECC-CAPABILITY TLV  . . . . . . . . . . . . . . . . . .  12
     8.2.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  12
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  12
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     10.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Contributor Addresses  . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   The Path Computation Element (PCE) [RFC4655] was developed to offload
   path computation function from routers in an MPLS traffic-engineered
   network.  Since then, the role and function of the PCE has grown to
   cover a number of other uses (such as GMPLS [RFC7025]) and to allow
   delegated control [RFC8231] and PCE-initiated use of network
   resources [RFC8281].

   According to [RFC7399], Software-Defined Networking (SDN) refers to a
   separation between the control elements and the forwarding components
   so that software running in a centralized system, called a
   controller, can act to program the devices in the network to behave
   in specific ways.  A required element in an SDN architecture is a
   component that plans how the network resources will be used and how
   the devices will be programmed.  It is possible to view this
   component as performing specific computations to place traffic flows
   within the network given knowledge of the availability of network
   resources, how other forwarding devices are programmed, and the way
   that other flows are routed.  This is the function and purpose of a
   PCE, and the way that a PCE integrates into a wider network control
   system (including an SDN system) is presented in [RFC7491].

   In early PCE implementations, where the PCE was used to derive paths
   for MPLS Label Switched Paths (LSPs), paths were requested by network
   elements (known as Path Computation Clients (PCCs)), and the results
   of the path computations were supplied to network elements using the
   Path Computation Element Communication Protocol (PCEP) [RFC5440].



Li, et al.              Expires January 14, 2021                [Page 3]


Internet-Draft                    PCECC                        July 2020


   This protocol was later extended to allow a PCE to send unsolicited
   requests to the network for LSP establishment [RFC8281].

   [RFC8283] introduces the architecture for PCE as a central controller
   as an extension of the architecture described in [RFC4655] and
   assumes the continued use of PCEP as the protocol used between PCE
   and PCC.  [RFC8283] further examines the motivations and
   applicability for PCEP as a Southbound Interface (SBI), and
   introduces the implications for the protocol.

   A PCE-based central controller (PCECC) can simplify the processing of
   a distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.  Thus, the LSP can be
   calculated/setup/initiated and the label forwarding entries can also
   be downloaded through a centralized PCE server to each network
   devices along the path while leveraging the existing PCE technologies
   as much as possible.

   [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the
   procedures and PCEP protocol extensions for using the PCE as the
   central controller for static P2P LSPs, where LSPs can be provisioned
   as explicit label instructions at each hop on the end-to-end path.
   Each router along the path must be told what label-forwarding
   instructions to program and what resources to reserve.  The PCE-based
   controller keeps a view of the network and determines the paths of
   the end-to-end LSPs, and the controller uses PCEP to communicate with
   each router along the path of the end-to-end LSP.

   [RFC4857] describes how to set up point-to-multipoint (P2MP) Traffic
   Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.  The
   PCE has been identified as a suitable application for the computation
   of paths for P2MP TE LSPs ([RFC5671]).  The extensions of PCEP to
   request path computation for P2MP TE LSPs are described in [RFC8306].
   Further [RFC8623] specify the extensions that are necessary in order
   for the deployment of stateful PCEs to support P2MP TE LSPs as well
   as the setup, maintenance and teardown of PCE-initiated P2MP LSPs
   under the stateful PCE model.

   This document extends
   [I-D.ietf-pce-pcep-extension-for-pce-controller] to specify the
   procedures and PCEP protocol extensions for using the PCE as the
   central controller for static P2MP LSPs, where LSPs can be
   provisioned as explicit label instructions at each hop on the end-to-
   end path with an added functionality of a P2MP branch node.  As per
   [RFC4875], a branch node is an LSR that replicates the incoming data
   on to one or more outgoing interfaces.




Li, et al.              Expires January 14, 2021                [Page 4]


Internet-Draft                    PCECC                        July 2020


   [I-D.ietf-teas-pcecc-use-cases] describes the use cases for P2MP in
   PCECC architecture.

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

2.  Terminology

   Terminologies used in this document is same as described in the draft
   [RFC8283] and [I-D.ietf-teas-pcecc-use-cases].

3.  Basic PCECC Mode

   As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], in
   this mode LSPs are provisioned as explicit label instructions at each
   hop on the end-to-end path.  Each router along the path must be told
   what label forwarding instructions to program and what resources to
   reserve.  The controller uses PCEP to communicate with each router
   along the path of the end-to-end LSP.  Note that the PCE-based
   controller will take responsibility for managing some part of the
   MPLS label space for each of the routers that it controls, and may
   taker wider responsibility for partitioning the label space for each
   router and allocating different parts for different uses.  This is
   also described in section 3.1.2. of [RFC8283].  For the purpose of
   this document, it is assumed that label range to be used by a PCE is
   known and set on both PCEP peers.  A future extension could add this
   capability to advertise the range via possible PCEP extensions as
   well.

   This document extends the functionality to include support for
   central control instruction for replication at the branch nodes.

   The rest of processing is similar to the existing stateful PCE
   mechanism for P2MP.

4.  Procedures for Using the PCE as the Central Controller (PCECC) for
    P2MP

4.1.  Stateful PCE Model

   Active stateful PCE is described in [RFC8231] and extended for P2MP
   [RFC8623].  PCE as a central controller (PCECC) reuses existing
   Active stateful PCE mechanism as much as possible to control the LSP.



Li, et al.              Expires January 14, 2021                [Page 5]


Internet-Draft                    PCECC                        July 2020


   [I-D.ietf-pce-pcep-extension-for-pce-controller] extends PCEP
   messages - PCRpt, PCInitiate, PCUpd message for the Central
   Controller's Instructions (CCI) (label forwarding instructions in the
   context of this document).  This documents specify the procedure for
   additional instruction for branch node needed for P2MP.

4.2.  PCECC Capability Advertisement

   As per [I-D.ietf-pce-pcep-extension-for-pce-controller], during PCEP
   Initialization Phase, PCEP Speakers (PCE or PCC) advertise their
   support of PCECC extensions by sending a PATH-SETUP-TYPE-CAPABILITY
   TLV in the OPEN object with this PST=PCECC included in the PST list.

   [I-D.ietf-pce-pcep-extension-for-pce-controller] also defines the
   PCECC Capability sub-TLV.  A new M-bit is added in PCECC-CAPABILITY
   TLV to indicate support for PCECC-P2MP.  A PCC MUST set M-bit in
   PCECC-CAPABILITY TLV and include STATEFUL-PCE-CAPABILITY TLV with
   P2MP bits set ([RFC8623]) in OPEN Object to support the PCECC P2MP
   extensions defined in this document.  If M-bit is set in PCECC-
   CAPABILITY TLV and N-bit in STATEFUL-PCE-CAPABILITY TLV is not set in
   OPEN Object, PCE SHOULD send a PCErr message with Error-Type=19
   (Invalid Operation) and Error-value=TBD2 (P2MP capability was not
   advertised) and terminate the session.

4.3.  LSP Operations

   The PCEP messages pertaining to PCECC MUST include PATH-SETUP-TYPE
   TLV [RFC8408] with PST=PCECC
   [I-D.ietf-pce-pcep-extension-for-pce-controller] in the SRP object to
   clearly identify the PCECC LSP is intended.

4.3.1.  Basic PCECC LSP Setup

   In order to setup a P2MP LSP based on PCECC mechanism, a PCC MUST
   delegate the P2MP LSP by sending a PCRpt message with PST set for
   PCECC and D (Delegate) flag (see [RFC8623]) set in the LSP object.

   P2MP-LSP-IDENTIFIER TLV [RFC8623] MUST be included for PCECC LSP, the
   tuple uniquely identifies the P2MP LSP in the network.  As per
   [I-D.ietf-pce-pcep-extension-for-pce-controller], the LSP object is
   included in central controller's instructions (label download) to
   identify the PCECC LSP for this instruction.

   When a PCE receives PCRpt message with D flags and PST Type set, it
   calculates the P2MP tree and assigns labels along the path; and set
   up the path by sending PCInitiate message to each node along the path
   of the LSP, similar to
   [I-D.ietf-pce-pcep-extension-for-pce-controller].  The new extension



Li, et al.              Expires January 14, 2021                [Page 6]


Internet-Draft                    PCECC                        July 2020


   required is the instructions on the branch nodes for replications to
   more than one outgoing interfaces with respective labels.  The rest
   of the operations remains same as
   [I-D.ietf-pce-pcep-extension-for-pce-controller] and [RFC8623].

4.3.2.  Central Control Instructions

   The new central controller's instructions (CCI) for the label
   operations in PCEP is done via the PCInitiate message as described in
   [I-D.ietf-pce-pcep-extension-for-pce-controller], by defining a new
   PCEP Objects for CCI operations.  Local label range of each PCC is
   assumed to be known at both the PCC and the PCE.

4.3.2.1.  Label Download CCI

   In order to setup an LSP based on PCECC, the PCE sends a PCInitiate
   message to each node along the path to download the Label instruction
   as described in Section 4.3.1.

   The CCI object MUST be included, along with the LSP object in the
   PCInitiate message.  As per
   [I-D.ietf-pce-pcep-extension-for-pce-controller], there are at most 2
   instances of CCI object in the PCInitiate message.  For PCECC-P2MP
   operations, multiple instances of CCI object for out-labels is
   allowed.  Similarly to acknowledge the central controller
   instructions, the PCRpt message allows multiple instances of CCI
   object for PCECC-P2MP operations.

   The LSP-IDENTIFIER TLV MUST be included in LSP object.  The SPEAKER-
   ENTITY-ID TLV SHOULD be included in LSP object.

   As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], if
   a node (PCC) receives a PCInitiate message which includes a Label to
   download as part of CCI, that is out of the range set aside for the
   PCE, it send a PCErr message with Error-type=TBD (PCECC failure) and
   Error-value=TBD (Label out of range) (defined in
   [I-D.ietf-pce-pcep-extension-for-pce-controller]).  If a PCC receives
   a PCInitiate message but failed to download the Label entry, it sends
   a PCErr message with Error-type=TBD (PCECC failure) and Error-
   value=TBD (Instruction failed) (defined in
   [I-D.ietf-pce-pcep-extension-for-pce-controller]).

   Consider the example in the [I-D.ietf-teas-pcecc-use-cases] -








Li, et al.              Expires January 14, 2021                [Page 7]


Internet-Draft                    PCECC                        July 2020


                          +----------+
                          |    R1    | Root node of the P2MP TE LSP
                          +----------+
                              |6000
                          +----------+
           Transit Node   |    R2    |
           branch         +----------+
                          *  |   *  *
                     9001*   |   *   *9002
                        *    |   *    *
           +-----------+     |   *     +-----------+
           |    R4     |     |   *     |    R5     | Transit Nodes
           +-----------+     |   *     +-----------+
                      *      |   *      *     +
                   9003*     |   *     *      +9004
                        *    |   *    *       +
                        +-----------+  +-----------+
                        |    R3     |  |    R6     | Leaf Node
                        +-----------+  +-----------+
                         9005|
                        +-----------+
                        |    R8     | Leaf Node
                        +-----------+


   PCECC would provision each node along the path and assign incoming
   and outgoing labels from R1 to {R6, R8} with the path: {R1, 6000},
   {6000, R2, {9001,9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003,
   R3, 9005}, {9004, R6}, {9005, R8}. The operations on all nodes except
   R2 are same as [I-D.ietf-pce-pcep-extension-for-pce-controller].  The
   branch node (R2) needs to be instructed to replicate two copies of
   the incoming packet, and sent towards R4 and R5 with 9001 and 9002
   labels respectively).  This done via including 3 instances of CCI
   objects in the PCEP messages, one for each label in the example, 6000
   for incoming and 9001/9002 for outgoing (along with remote nexthop).
   The message and procedure remains exactly as
   [I-D.ietf-pce-pcep-extension-for-pce-controller] with only
   distinction that more than one outgoing CCI MAY be present for the
   P2MP LSP.

4.3.2.2.  Label Cleanup CCI

   In order to delete an P2MP LSP based on PCECC, the PCE sends a
   central controller instructions via a PCInitiate message to each node
   along the path of the LSP to cleanup the Label forwarding instruction
   as per [I-D.ietf-pce-pcep-extension-for-pce-controller].  In case of
   branch nodes all instances of CCIs needs to be present in the PCEP
   message.



Li, et al.              Expires January 14, 2021                [Page 8]


Internet-Draft                    PCECC                        July 2020


4.3.3.  PCE Initiated PCECC LSP

   The LSP Instantiation operation is same as defined in [RFC8281] and
   [RFC8623].

   In order to setup a P2MP PCE Initiated LSP based on the PCECC
   mechanism, a PCE sends PCInitiate message with Path Setup Type set
   for PCECC (see Section 5.2) to the Ingress PCC (root).

   The Ingress PCC MUST also set D (Delegate) flag (see [RFC8231]) and C
   (Create) flag (see [RFC8281]) in LSP object of PCRpt message.  The
   PCC responds with first PCRpt message with the status as "GOING-UP"
   and assigned PLSP-ID.

   As described in [I-D.ietf-pce-pcep-extension-for-pce-controller], the
   label forwarding instructions from PCECC are send after the initial
   PCInitiate and PCRpt exchange.  This is done so that the PLSP-ID and
   other LSP identifiers can be obtained from the ingress and can be
   included in the label forwarding instruction in the next PCInitiate
   message.  The rest of the PCECC LSP setup operations are same as
   those described in Section 4.3.1.

4.3.4.  PCECC LSP Update

   In case of a modification of PCECC P2MP LSP with a new path, the
   procedure and instructions as described in
   [I-D.ietf-pce-pcep-extension-for-pce-controller] apply.

4.3.5.  Re-Delegation and Cleanup

   In case of a redelegation and cleanup of PCECC P2MP LSP, the
   procedure and instructions as described in
   [I-D.ietf-pce-pcep-extension-for-pce-controller] apply.

4.3.6.  Synchronization of Central Controllers Instructions

   The procedure and instructions are as per
   [I-D.ietf-pce-pcep-extension-for-pce-controller].

4.3.7.  PCECC LSP State Report

   An Ingress PCC MAY choose to apply any OAM mechanism to check the
   status of LSP in the Data plane and MAY further send its status in
   PCRpt message (as per [RFC8623]) to the PCE.







Li, et al.              Expires January 14, 2021                [Page 9]


Internet-Draft                    PCECC                        July 2020


5.  PCEP Objects

5.1.  OPEN Object

5.1.1.  PCECC Capability sub-TLV

   The PCECC-CAPABILITY sub-TLV is an optional TLV for use in the OPEN
   Object for PCECC capability advertisement in PATH-SETUP-TYPE-
   CAPABILITY TLV as specified in
   [I-D.ietf-pce-pcep-extension-for-pce-controller].

   This document adds a new flag (M-bit) in PCECC-CAPABILITY sub-TLV to
   indicate the support for P2MP in PCECC.  A PCC MUST set M-bit in
   PCECC-CAPABILITY sub-TLV and set the N (P2MP-CAPABILITY), M (P2MP-
   LSP-UPDATE-CAPABILITY), and P (P2MP-LSP-INSTANTIATION-CAPABILITY) (as
   per [RFC8623]) in STATEFUL-PCE-CAPABILITY TLV [RFC8231] to support
   the PCECC P2MP extensions defined in this document.  If M-bit is set
   in PCECC-CAPABILITY sub-TLV and the P2MP bits in STATEFUL-PCE-
   CAPABILITY TLV are not set in OPEN Object, PCE SHOULD send a PCErr
   message with Error-Type=19 (Invalid Operation) and Error-value=TBD2
   (P2MP capability was not advertised) and terminate the session.

5.2.  PATH-SETUP-TYPE TLV

   The PATH-SETUP-TYPE TLV is defined in [RFC8408];
   [I-D.ietf-pce-pcep-extension-for-pce-controller] defines a PST value
   for PCECC, which is also used for P2MP.

5.3.  CCI Object

   The Central Control Instructions (CCI) Object
   [I-D.ietf-pce-pcep-extension-for-pce-controller] is used by the PCE
   to specify the forwarding instructions (Label information in the
   context of this document) to the PCC, and optionally carried within
   PCInitiate or PCRpt message for label download which defined Object
   Type 1 for MPLS Label, which is also used for P2MP.  The address TLVs
   [I-D.ietf-pce-pcep-extension-for-pce-controller] associates the next-
   hop information in case of an outgoing label.

   If a node (PCC) receives a PCInitiate/PCUpd message with more than
   one CCI with O-bit set for outgoing label and the node does not
   support the P2MP branch/replication capability, it MUST respond with
   PCErr message with Error-Type=2 (Capability not supported) (defined
   in [RFC5440]).







Li, et al.              Expires January 14, 2021               [Page 10]


Internet-Draft                    PCECC                        July 2020


6.  Security Considerations

   The security considerations described in [RFC8231], [RFC8281],
   [RFC8623], and [I-D.ietf-pce-pcep-extension-for-pce-controller] apply
   to the extensions described in this document.

7.  Manageability Considerations

7.1.  Control of Function and Policy

   A PCE or PCC implementation SHOULD allow to configure to enable/
   disable PCECC P2MP capability as a global configuration.

7.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB, this MIB can be extended to get the
   PCECC capability status.

   The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to
   enable/disable PCECC P2MP capability.

7.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

7.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440] and [RFC8231].

7.5.  Requirements On Other Protocols

   PCEP extensions defined in this document do not put new requirements
   on other protocols.

7.6.  Impact On Network Operations

   PCEP extensions defined in this document do not put new requirements
   on network operations.

8.  IANA Considerations







Li, et al.              Expires January 14, 2021               [Page 11]


Internet-Draft                    PCECC                        July 2020


8.1.  PCECC-CAPABILITY TLV

   [I-D.ietf-pce-pcep-extension-for-pce-controller] defines the PCECC-
   CAPABILITY TLV and requests that IANA creates a registry to manage
   the value of the PCECC-CAPABILITY TLV's Flag field.  IANA is
   requested to allocate a new bit in the PCECC-CAPABILITY TLV Flag
   Field registry, as follows:

          Bit            Description                Reference
          TBD1           M((PCECC-P2MP-CAPABILITY)) This document

8.2.  PCEP-Error Object

   IANA is requested to allocate new error types and error values within
   the "PCEP-ERROR Object Error Types and Values" sub-registry of the
   PCEP Numbers registry for the following errors:


   Error-Type   Meaning
   ----------   -------
   19           Invalid operation.

                 Error-value = TBD2 :                P2MP capability was
                                                     not advertised

9.  Acknowledgments

10.  References

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

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <https://www.rfc-editor.org/info/rfc7420>.





Li, et al.              Expires January 14, 2021               [Page 12]


Internet-Draft                    PCECC                        July 2020


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

   [RFC8623]  Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful
              Path Computation Element (PCE) Protocol Extensions for
              Usage with Point-to-Multipoint TE Label Switched Paths
              (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019,
              <https://www.rfc-editor.org/info/rfc8623>.

   [I-D.ietf-pce-pcep-extension-for-pce-controller]
              Zhao, Q., Li, Z., Negi, M., Peng, S., and C. Zhou, "PCEP
              Procedures and Protocol Extensions for Using PCE as a
              Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep-
              extension-for-pce-controller-05 (work in progress), June
              2020.

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

   [RFC4857]  Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4
              Regional Registration", RFC 4857, DOI 10.17487/RFC4857,
              June 2007, <https://www.rfc-editor.org/info/rfc4857>.

   [RFC4875]  Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
              Yasukawa, Ed., "Extensions to Resource Reservation
              Protocol - Traffic Engineering (RSVP-TE) for Point-to-
              Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
              DOI 10.17487/RFC4875, May 2007,
              <https://www.rfc-editor.org/info/rfc4875>.





Li, et al.              Expires January 14, 2021               [Page 13]


Internet-Draft                    PCECC                        July 2020


   [RFC5671]  Yasukawa, S. and A. Farrel, Ed., "Applicability of the
              Path Computation Element (PCE) to Point-to-Multipoint
              (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671,
              DOI 10.17487/RFC5671, October 2009,
              <https://www.rfc-editor.org/info/rfc5671>.

   [RFC7025]  Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
              Margaria, "Requirements for GMPLS Applications of PCE",
              RFC 7025, DOI 10.17487/RFC7025, September 2013,
              <https://www.rfc-editor.org/info/rfc7025>.

   [RFC7399]  Farrel, A. and D. King, "Unanswered Questions in the Path
              Computation Element Architecture", RFC 7399,
              DOI 10.17487/RFC7399, October 2014,
              <https://www.rfc-editor.org/info/rfc7399>.

   [RFC7491]  King, D. and A. Farrel, "A PCE-Based Architecture for
              Application-Based Network Operations", RFC 7491,
              DOI 10.17487/RFC7491, March 2015,
              <https://www.rfc-editor.org/info/rfc7491>.

   [RFC8283]  Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
              Architecture for Use of PCE and the PCE Communication
              Protocol (PCEP) in a Network with Central Control",
              RFC 8283, DOI 10.17487/RFC8283, December 2017,
              <https://www.rfc-editor.org/info/rfc8283>.

   [RFC8306]  Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King,
              "Extensions to the Path Computation Element Communication
              Protocol (PCEP) for Point-to-Multipoint Traffic
              Engineering Label Switched Paths", RFC 8306,
              DOI 10.17487/RFC8306, November 2017,
              <https://www.rfc-editor.org/info/rfc8306>.

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

   [I-D.ietf-teas-pcecc-use-cases]
              Zhao, Q., Li, Z., Khasanov, B., Dhody, D., Ke, Z., Fang,
              L., Zhou, C., Communications, T., Rachitskiy, A., and A.
              Gulida, "The Use Cases for Path Computation Element (PCE)
              as a Central Controller (PCECC).", draft-ietf-teas-pcecc-
              use-cases-05 (work in progress), March 2020.






Li, et al.              Expires January 14, 2021               [Page 14]


Internet-Draft                    PCECC                        July 2020


   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A
              YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", draft-ietf-pce-pcep-
              yang-13 (work in progress), October 2019.














































Li, et al.              Expires January 14, 2021               [Page 15]


Internet-Draft                    PCECC                        July 2020


Appendix A.  Contributor Addresses

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

   EMail: dhruv.ietf@gmail.com

   Udayasree Palle

   EMail: udayasreereddy@gmail.com


Authors' Addresses

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

   EMail: lizhenbin@huawei.com


   Shuping Peng
   Huawei Technologies
   Huawei Bld., No.156 Beiqing Rd.
   Beijing  100095
   China

   EMail: pengshuping@huawei.com


   Xuesong Geng
   Huawei Technologies
   China

   EMail: gengxuesong@huawei.com











Li, et al.              Expires January 14, 2021               [Page 16]


Internet-Draft                    PCECC                        July 2020


   Mahendra Singh Negi
   RtBrick India
   N-17L, Floor-1, 18th Cross Rd, HSR Layout Sector-3
   Bangalore, Karnataka  560102
   India

   EMail: mahend.ietf@gmail.com












































Li, et al.              Expires January 14, 2021               [Page 17]


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