PCE Working Group

Internet Engineering Task Force (IETF)                          I. Minei
Internet-Draft
Request for Comments: 8697                                  Google, Inc.
Intended status:
Category: Standards Track                                      E. Crabbe
Expires: February 2, 2020
ISSN: 2070-1721                                   Individual Contributor
                                                            S. Sivabalan
                                                     Cisco Systems, Inc.
                                                      H. Ananthakrishnan
                                                                 Netflix
                                                                D. Dhody
                                                                  Huawei
                                                               Y. Tanaka
                                          NTT Communications Corporation
                                                          August 1, 2019
                                                            January 2020

 Path Computation Element Communication Protocol (PCEP) Extensions for
 Establishing Relationships Between between Sets of Label Switched Paths (LSPs)
                  draft-ietf-pce-association-group-10

Abstract

   This document introduces a generic mechanism to create a grouping of
   Label Switched Paths (LSPs) in the context of a Path Computation
   Element (PCE).  This grouping can then be used to define associations
   between sets of LSPs or between a set of LSPs and a set of attributes
   (such as configuration parameters or behaviours), behaviors), and it is equally
   applicable to the stateful PCE (active and passive modes) as well as and the
   stateless PCE.

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 an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 2, 2020.
   https://www.rfc-editor.org/info/rfc8697.

Copyright Notice

   Copyright (c) 2019 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
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   4  Motivations
     3.2.  Relationship with to the SVEC List . . . . . . . . . . . . .   5
     3.3.  Operation  Operational Overview  . . . . . . . . . . . . . . . . . . .   5
     3.4.  Operator-configured  Operator-Configured Association Range . . . . . . . . . .   6
   4.  Discovery of Supported Association Types  . . . . . . . . . .   7
     4.1.  ASSOC-Type-List TLV . . . . . . . . . . . . . . . . . . .   7
       4.1.1.  Procedure . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Operator-configured  Operator-Configured Association Range TLV . . . . . . . . . .   8
     5.1.  Procedure . . . . . . . . . . . . . . . . . . . . . . . .  10
   6.  ASSOCIATION Object  . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Object Definition . . . . . . . . . . . . . . . . . . . .  11
       6.1.1.  Global Association Source TLV . . . . . . . . . . . .  13
       6.1.2.  Extended Association ID TLV . . . . . . . . . . . . .  13
       6.1.3.  Association Source  . . . . . . . . . . . . . . . . .  14
       6.1.4.  Unique Identification for an Association Group  . . .  14
     6.2.  Relationship with to the RSVP ASSOCIATION  . . . . . . . . .  15 Object
     6.3.  Object Encoding in PCEP messages  . . . . . . . . . . . .  15 Messages
       6.3.1.  Stateful PCEP messages  . . . . . . . . . . . . . . .  15 Messages
       6.3.2.  Request Message . . . . . . . . . . . . . . . . . . .  17
       6.3.3.  Reply Message . . . . . . . . . . . . . . . . . . . .  18
     6.4.  Processing Rules  . . . . . . . . . . . . . . . . . . . .  19
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  PCEP Object . . . . . . . . . . . . . . . . . . . . . . .  21
     7.2.  PCEP TLV  . . . . . . . . . . . . . . . . . . . . . . . .  22
     7.3.  Association Flags . . . . . . . . . . . . . . . . . . . .  22
     7.4.  Association Type  . . . . . . . . . . . . . . . . . . . .  23
     7.5.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .  23
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .  24
     9.1.  Control of Function and Policy  . . . . . . . . . . . . .  24
     9.2.  Information and Data Models . . . . . . . . . . . . . . .  24
     9.3.  Liveness Detection and Monitoring . . . . . . . . . . . .  25
     9.4.  Verify  Verifying Correct Operations . . . . . . . . . . . . . . . .  25 Operation
     9.5.  Requirements on Other Protocols . . . . . . . . . . . . .  25
     9.6.  Impact on Network Operations  . . . . . . . . . . . . . .  25
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  25
   11. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  25
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
     12.1.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  26
     12.2.
     10.2.  Informative References . . . . . . . . . . . . . . . . .  27
   Appendix A.  Example for Operator-configured of an Operator-Configured Association Range  .  28
   Acknowledgments
   Contributors
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

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 a PCE and another PCE,
   for the purpose of the computation of Multiprotocol Label Switching
   (MPLS) as well as Generalized 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 operational model of operation
   where
   whereby LSPs are initiated from the PCE is described in [RFC8281].

   [RFC4872] defines the RSVP ASSOCIATION object, which was defined in
   the context of GMPLS-controlled Label Switched Paths (LSPs) LSPs to be used to associate recovery
   LSPs with the LSP they are protecting.  This object also has broader
   applicability as a mechanism to associate RSVP state and state.  [RFC6780] described
   describes how the ASSOCIATION object can be more generally applied by
   defining the Extended ASSOCIATION Object. object.

   This document introduces a generic mechanism to create a grouping of
   LSPs.  This grouping can then be used to define associations between
   sets of LSPs or between a set of LSPs and a set of attributes (such
   as configuration parameters or behaviours), behaviors), and it is equally
   applicable to the stateful PCE (active and passive modes) and the
   stateless PCE.  The associations could be created dynamically and
   conveyed to a PCEP peer within PCEP, or it they could be configured
   manually by an operator on the PCEP peers.  Refer to Section 3.3 for
   more details.

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

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE,

   *  PCC

   *  PCE

   *  PCEP Peer, Peer

   *  Path Computation Request (PCReq), (PCReq)

   *  Path Computation Reply (PCRep), and (PCRep)

   *  PCEP Error (PCErr). (PCErr)

   This document uses the following terms defined in [RFC8051]:

   *  Stateful
   PCE, PCE

   *  Active Stateful PCE, PCE

   *  Passive Stateful PCE, and Delegation. PCE

   *  Delegation

   This document uses the following terms defined in [RFC8231]:

   *  LSP State Report (PCRpt), (PCRpt)

   *  LSP Update Request (PCUpd), and (PCUpd)

   *  State Timeout
   Interval. Interval

   This document uses the following terms defined in [RFC8281]: PCE-
   initiated LSP, and

   *  PCE-initiated LSP

   *  LSP Initiate Request (PCInitiate). (PCInitiate)

3.  Architectural Overview

3.1.  Motivation

   Stateful  Motivations

   A stateful PCE provides the ability to update existing LSPs and to
   instantiate new ones.  There are various situations where several
   LSPs need to share common information.  E.g.,  For example, to support for PCE-
   controlled make-before-break, an association between the original
   path and the re-optimized reoptimized path is desired.  Similarly, for end-to-end
   protection, the an association between working and protection LSPs is
   required (see [I-D.ietf-pce-stateful-path-protection]). [PCE-PROTECTION]).  For diverse paths, an association
   between a group of LSPs could be used (see
   [I-D.ietf-pce-association-diversity]). [PCE-DIVERSITY]).  Another
   use for the an LSP grouping is for applying would be to apply a common set of
   configuration parameters or
   behaviours behaviors to a set of LSPs.

   For a stateless PCE, it might be useful to associate a path
   computation request PCReq message
   to an association group, thus enabling it to associate a common set
   of policy, policies, configuration parameters parameters, or
   behaviours behaviors with the request.

   Some associations could be created dynamically, such as an
   association between the working and protection LSPs of a tunnel,
   whereas some associations could be created by the operator manually,
   such as a policy-based association, association where the LSP could join an operator-
   configured
   operator-configured existing association.

   Rather than creating separate mechanisms for each use case, this
   document defines a generic mechanism that can be reused as needed.

3.2.  Relationship with to the SVEC List

   Note that, that [RFC5440] defines a mechanism for the synchronization of a
   set of path computation requests PCReq messages by using the SVEC (Synchronization VECtor)
   object, that which specifies the list of synchronized requests that can either be
   either dependent or independent.  The SVEC object identifies the
   relationship between the set of path computation requests, PCReq messages, identified by 'Request-ID-number'
   "Request-ID-number" in the RP (Request Parameters) object.  [RFC6007]
   further clarifies the use of the SVEC list for synchronized path
   computations when computing dependent requests as well as requests, and it describes a
   number of usage scenarios for SVEC lists within single-
   domain single-domain and
   multi-domain environments.

   The motivation motivations behind the association group defined in this document
   and the SVEC object are quite different, though some use cases may
   overlap.  PCEP extensions that define a new association type Association Type should
   clarify the relationship between the SVEC object and the association
   type, Association
   Type, if any.

3.3.  Operation  Operational Overview

   LSPs are associated with other LSPs with which they interact by
   adding them to a common association group.  Association groups as
   defined in this document can be applied to LSPs originating at the
   same head end headend or different head ends. headends.

   Some associations could be created dynamically by a PCEP speaker speaker, and
   the associations (along with the set of LSPs) are conveyed to a PCEP
   peer.  Whereas some associations are configured by the operator
   beforehand on the PCEP peers involved beforehand, in question, a PCEP speaker then could then
   ask for
   a an LSP to join the operator-configured association. Operator-configured Association.  Usage of
   dynamic and configured association associations is usually dependent on the type
   of the association.

   For the operator-configured association, Operator-configured Associations, the association parameters parameters,
   such as the association identifier, association type, as well as Association Identifier (Association ID), Association
   Type, and the
   association source Association Source IP address, are manually configured
   by the operator.  In the case of a dynamic association, the
   association parameters parameters, such as the association identifier, Association ID, are allocated
   dynamically by the PCEP speaker, the association source speaker.  The Association Source is set as
   the local PCEP speaker
   address, address unless local policy dictates
   otherwise, in which case
   association source the Association Source is set based on the
   local policy.

   The dynamically created association can be reported to the PCEP peer
   via the PCEP messages as per the stateful extensions.  When the
   operator-configured association
   Operator-configured Association is known to the PCEP peer beforehand,
   a PCEP peer could ask for a an LSP to join the operator-configured
   association Operator-configured
   Association via the stateful PCEP messages.

   The associations are properties of the LSP and thus could be stored
   in the LSP state database.  The dynamic association exists as long as
   the LSP state exists.  In the case of PCEP session termination, the
   LSP state clean-up cleanup MUST also take care of associations.

   Multiple types of associations can exist, each with their its own
   association identifier
   Association ID space.  The definition of the different
   association types Association
   Types and their behaviours behaviors is outside the scope of this document.  The
   establishment and removal of the association relationship can be done
   on a per LSP per-LSP basis.  An LSP may join multiple association groups, of different or of groups that
   have the same association
   type. Association Type or different Association Types.

3.4.  Operator-configured  Operator-Configured Association Range

   Some association types Association Types are dynamic, some are operator-configured operator configured, and
   some could be both.  For the association types Association Types that could be both
   dynamic and operator-configured operator configured and use the same association source, Association Source,
   it is necessary to distinguish a range of association identifiers Association IDs that are
   marked for operator-configured associations Operator-configured Associations, to avoid any
   association identifier clash Association
   ID clashes within the scope of the association
   source. Association Source.  This document
   assumes that these two ranges are configured.

   A range of association identifiers Association IDs for each Association type Type (and Association
   Source) are is kept for the operator-configured
   associations. Operator-configured Associations.  Dynamic
   associations MUST NOT use the association
   identifier Association ID from this range.

   This range range, as set at the PCEP speaker (PCC (a PCC or PCE, as an association
   source)
   Association Source), needs to be communicated to a PCEP peer in the
   Open Message. message.  A new TLV is defined in this specification for this
   purpose (Section 5).  See Appendix A for an example.

   The Association identifier ID range for sources other than the PCEP speaker (for example an NMS system)
   example, a Network Management System (NMS)) is not communicated in PCEP
   PCEP, and the procedure for operator-configured association range setting Operator-configured Association Range
   settings is outside the scope of this document.

4.  Discovery of Supported Association Types

   This section defines PCEP extensions so as to support the capability
   advertisement of the association types Association Types supported by a PCEP speaker.

   A new PCEP ASSOC-Type-List (Association Types list) TLV is defined.
   The PCEP ASSOC-Type-List TLV is carried within an OPEN object.  This
   way, during the PCEP session-setup phase, a PCEP speaker can
   advertise to a PCEP peer the list of supported Association types. Types.

4.1.  ASSOC-Type-List TLV

   The PCEP ASSOC-Type-List TLV is OPTIONAL.  It MAY be carried within
   an OPEN object sent by a PCEP speaker in an Open message to a PCEP
   peer so as to indicate the list of supported Association types. Types.

   The PCEP ASSOC-Type-List TLV format is compliant with the PCEP TLV
   format defined in [RFC5440].  That is, the TLV is composed of 2
   octets for the type, 2 octets specifying the TLV length, and a Value
   field.  The Length field defines the length of the value portion in
   octets.  The TLV is padded to 4-octet alignment, and padding is not
   included in the Length field (e.g., a 3-octet value would have a
   length of three, but the total size of the TLV would be eight 8 octets).

   The PCEP ASSOC-Type-List TLV has the following format:

   TYPE:    TBD
   LENGTH:  N * 2 (where N is the number of association types)
   VALUE:   list of 2-byte association type code points, identifying
            the association types supported by the sender of the Open
            message.

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Assoc-type          Assoc-Type #1        |      Assoc-type      Assoc-Type #2            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Assoc-type          Assoc-Type #N        |       padding                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 1: The ASSOC-Type-List TLV format
   Assoc-type (2 bytes): Format

   Type:  35

   Length:  N * 2 (where N is the number of Association type Types).

   Value:  List of 2-byte Association Type code point identifier.  IANA
   manages points, identifying the
      Association Types supported by the sender of the Open message.

   Assoc-Type (2 bytes):  Association Type code point identifier.  IANA
      manages the "ASSOCIATION Type Field" code point registry (see
      Section 7.4).

4.1.1.  Procedure

   An ASSOC-Type-List TLV within an OPEN object in an Open message is
   included by a PCEP speaker in order to advertise a set of one or more
   supported association types. Association Types.  The ASSOC-Type-List TLV MUST NOT appear
   more than once in an OPEN object.  If it appears more than once, the
   PCEP session MUST be rejected with error type Error-Type 1 and error value Error-value 1
   (PCEP session establishment failure / Reception of an invalid Open
   message).  As specified in [RFC5440], a PCEP peer that does not
   recognize the ASSOC-Type-List TLV will silently ignore it.

   The Association type Type (to be defined in other future documents) can specify
   if the association type Association Type advertisement is mandatory for it.  Thus, the
   ASSOC-Type-List TLV MUST be included if at least one mandatory
   association type
   Association Type needs to be advertised advertised, and the ASSOC-Type-List TLV
   MAY be included otherwise.  For an association type Association Type that specifies
   that the advertisement is mandatory, a missing Assoc-type Assoc-Type in the
   ASSOC-Type-List TLV (or a missing ASSOC-Type-List TLV) is to be
   interpreted as meaning that the association type Association Type is not supported by
   the PCEP speaker.

   The absence of the ASSOC-Type-List TLV in an OPEN object MUST be
   interpreted as an absence of information on in the list of supported
   Association types Types (rather than an indication that the Association type
   Type is not supported).  In this case, the PCEP speaker could still
   use the ASSOCIATION object: if the peer does not support the
   association, it will react as per the procedure described in
   Section 6.4.

   In case

   If the use of the ASSOC-Type-List TLV is triggered by support for a
   mandatory association type, Association Type, then it is RECOMMENDED that the PCEP
   implementation include all supported Association types Types (including optional)
   optional types) to ease the operations of the PCEP peer.

5.  Operator-configured  Operator-Configured Association Range TLV

   This section defines a PCEP extension to support the advertisement of
   the Operator-configured Association Range used for an Association
   type
   Type by the PCEP speaker (as an Association source). Source).

   A new PCEP OP-CONF-ASSOC-RANGE (Operator-configured Association
   Range) TLV is defined.  The PCEP OP-CONF-ASSOC-RANGE TLV is carried
   within an OPEN object.  This way, during the PCEP session-setup
   phase, a PCEP speaker can advertise to a PCEP peer the Operator-configured Operator-
   configured Association Range for an association type. Association Type.

   The PCEP OP-CONF-ASSOC-RANGE TLV is OPTIONAL.  It MAY be carried
   within an OPEN object sent by a PCEP speaker in an Open message to a
   PCEP peer.  The OP-CONF-ASSOC-RANGE TLV format is compliant with the
   PCEP TLV format defined in [RFC5440].  That is, the TLV is composed
   of 2 bytes for the type, 2 bytes specifying the TLV length, and a
   Value field.  The Length field defines the length of the value
   portion in bytes.

   The PCEP OP-CONF-ASSOC-RANGE TLV has the following format:

   TYPE:    29 (Early allocation by IANA)
   LENGTH:  N * 8 (where N is the number of association types)
   VALUE:

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Reserved          |          Assoc-type          Assoc-Type #1        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Start-Assoc-ID #1        |           Range #1            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Reserved          |          Assoc-type          Assoc-Type #N        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Start-Assoc-ID #N        |           Range #N            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 2: The OP-CONF-ASSOC-RANGE TLV format

   The Value portion includes Format

   Type:  29

   Length:  N * 8 (where N is the number of Association Types).

   Value:  Includes the following fields, repeated for each
   association type: Association
      Type:

      Reserved (2 bytes): This field  MUST be set to 0 on transmission and MUST be
         ignored on receipt.

      Assoc-type

      Assoc-Type (2 bytes):  The association type Association Type (Section 7.4).  The
      association types are
         Association Types will be defined in separate future documents.

      Start-Assoc-ID (2 bytes):  The start association "start association" identifier for
         the Operator-configured Association Range for the particular
      association type.
         Association Type.  The values 0 and 0xffff MUST NOT be used and used; on
         receipt of these values in the TLV, the session is rejected with rejected,
         and an error message is sent (see Section 5.1).

      Range (2 bytes):  The number of associations marked for the
         Operator-configured Associations.  The  Range MUST be greater than
         0, and it MUST be such that (Start-Assoc-ID + Range) do does not
         cross the association identifier range largest Association ID value of 0xffff.  In case  If this
         condition is not satisfied, the session is rejected with rejected, and an
         error message is sent (see Section 5.1).

5.1.  Procedure

   A PCEP speaker MAY include an OP-CONF-ASSOC-RANGE TLV within an OPEN
   object in an Open message sent to a PCEP peer in order to advertise
   the Operator-configured Association Range for an association type. Association Type.
   The OP-CONF-ASSOC-RANGE TLV MUST NOT appear more than once in an OPEN
   object.  If it appears more than once, the PCEP session MUST be
   rejected with error type Error-Type 1 and error value Error-value 1 (PCEP session
   establishment failure / Reception of an invalid Open message).

   As specified in [RFC5440], a PCEP peer that does not recognize the
   OP-CONF-ASSOC-RANGE TLV will silently ignore it.

   The Operator-configured Association Range SHOULD be included for each
   association type
   Association Type that could be both dynamic and operator-configured. operator configured.
   For association types Association Types that are only dynamic or only operator- operator
   configured, this TLV MAY be skipped, in which case the full range of
   association identifier
   Association IDs is considered dynamic or operator-configured operator configured,
   respectively.  Each association type (that are Association Type (to be defined in separate future
   documents) can specify the default value for the operator-configured
   association range for their respective association type. its Operator-configured
   Association Range.

   The absence of the OP-CONF-ASSOC-RANGE TLV in an OPEN object MUST be
   interpreted as an absence of an explicit Operator-configured
   Association Range at the PCEP peer.  In this case, the default
   behavior as per each association type Association Type applies.  If the association source Association
   Source is not a PCEP speaker, the default value for the operator-configured
   association range Operator-
   configured Association Range is used for the association source. Association Source.

   If the Assoc-type Assoc-Type is not recognized or supported by the PCEP speaker,
   it MUST ignore that respective Start-Assoc-ID and Range. (Start-Assoc-ID + Range).  If the
   Assoc-type
   Assoc-Type is recognized/supported but the Start-Assoc-ID or Range
   are is set
   incorrectly, the PCEP session MUST be rejected with error
   type Error-Type 1 and error value
   Error-value 1 (PCEP session establishment failure / Reception of an
   invalid Open message).  The incorrect range include includes the case when
   the (Start-Assoc-ID + Range) crosses the association
   identifier range largest Association ID value
   of 0xffff.

   A given Assoc-type Assoc-Type MAY appear more than once in the OP-CONF-ASSOC-
   RANGE TLV in the case of a non-contiguous Operator-configured
   Association Range.  The PCEP speaker originating this TLV MUST NOT
   carry
   send overlapping ranges for an association type. Association Type.  If a PCEP peer
   receives overlapping ranges for an association type, Association Type, it MUST consider
   the Open message malformed and MUST reject the PCEP session with
   error type
   Error-Type 1 and error value Error-value 1 (PCEP session establishment failure /
   Reception of an invalid Open message).

   There may be cases where an operator-configured association Operator-configured Association was
   configured with association parameters (such as association
   identifier, association type an Association ID,
   Association Type, and association source) Association Source) at the local PCEP speaker,
   and later the PCEP session gets is later established with the
   association source Association Source
   and a new operator-configured range is learned during session
   establishment.  At this time, the local PCEP speaker MUST remove any
   associations that are not in the new operator-
   configured operator-configured range (by
   disassociating any LSPs that are part of it (and notifying this change to the PCEP peer)).
   peer of this change)).  If a PCEP speaker receives an association for
   an operator-configured association Operator-configured Association and the
   association identifier Association ID is not in
   the operator-configured association
   range Operator-configured Association Range for the association type Association Type
   and association source, Association Source, it MUST generate an error (as described in
   Section 6.4).

6.  ASSOCIATION Object

6.1.  Object Definition

   Association groups and their memberships are defined using a new
   ASSOCIATION object.

   The ASSOCIATION Object-Class value is 40 (Early allocation by IANA). 40.

   The ASSOCIATION Object-Type value is 1 for IPv4 IPv4, and its format is
   shown in Figure 3:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Flags            |R|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Association type Type         |      Association ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              IPv4 Association Source                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   Optional TLVs                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: The IPv4 ASSOCIATION Object format Format

   The ASSOCIATION Object-Type value is 2 for IPv6 IPv6, and its format is
   shown in Figure 4:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Flags            |R|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      Association type Type         |      Association ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                    IPv6 Association Source                    |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                   Optional TLVs                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: The IPv6 ASSOCIATION Object format Format

   Reserved (2-byte): (2 bytes):  MUST be set to 0 and ignored upon receipt.

   Flags (2-byte): (2 bytes):  The following flags are flag is currently defined:

      R (Removal - 1 bit):  when  When set, the requesting PCEP peer requires
         the removal of an LSP from the association group.  When unset,
         the PCEP peer indicates that the LSP is added or retained as
         part of the association group.  This flag is used for the
         ASSOCIATION object in the PCRpt Path Computation Report (PCRpt) and the PCUpd message, the flag
         Path Computation Update (PCUpd) messages.  It is ignored in
         other PCEP messages.

   The unassigned flags MUST be set to zero 0 on transmission and MUST be
   ignored on receipt.

   Association type (2-byte): the association type Type (2 bytes):  The Association Type (Section 7.4).  The
   association types are
      Association Types will be defined in separate future documents.

   Association ID (2-byte): the (2 bytes):  The identifier of the association group.
      When combined with other association parameters, such as an
      Association Type and Association Source, this value uniquely
      identifies an association group.  The values 0xffff and 0x0 are
      reserved.  The value 0xffff is used to indicate all association
      groups and could be used with the R flag to indicate removal for
      all associations for the LSP within the scope of association type the Association
      Type and association source. Association Source.

   Association Source:  Contains a valid IPv4 address (4 bytes) if the
      ASSOCIATION Object-Type is 1 or a valid IPv6 address (16 bytes) if
      the ASSOCIATION Object-Type is 2.  The address provides scoping
      for the Association ID.  See Section 6.1.3 for details.

   Optional TLVs:  The optional TLVs follow the PCEP TLV format of defined
      in [RFC5440].  This document defines two optional TLVs.  Other
      documents can define more TLVs in the future.

6.1.1.  Global Association Source TLV

   The Global Association Source TLV is an optional TLV for use in the
   Association Object.
   ASSOCIATION object.  The meaning and the usage of the Global Association
   Source is TLV are as per Section 4 of [RFC6780].

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              Global Association Source                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 5: The Global Association Source TLV format Format

   Type:  30 (Early allocation by IANA).

   Length:  Fixed value of 4 bytes.

   Global Association Source: as  As defined in Section 4 of [RFC6780].

6.1.2.  Extended Association ID TLV

   The Extended Association ID TLV is an optional TLV for use in the
   Association Object.
   ASSOCIATION object.  The meaning and the usage of the Extended
   Association ID is TLV are as per Section 4 of [RFC6780].

      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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                Extended Association ID                      //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 6: The Extended Association ID TLV format Format

   Type:  31 (Early allocation by IANA).

   Length: variable.  Variable.

   Extended Association ID: as  As defined in Section 4 of [RFC6780].

6.1.3.  Association Source

   The Association Source field in the ASSOCIATION object is set to a
   valid IP address to identify the node that originates originated the
   association.  In the case of dynamic associations, the association source Association
   Source is usually set as the local PCEP speaker address, address unless local
   policy dictates otherwise, in which case association source the Association Source is
   set based on the local policy.  In the case of PCE redundancy, local
   policy could set the source as a virtual IP address which that identifies
   all instances of the PCE.  In the case of operator-configured association, Operator-configured
   Associations, the association
   source Association Source is manually configured configured, and it
   could be set as one of the PCEP speakers, Network Management System (NMS), an NMS, or any other valid
   IP address that scopes the association identifier Association ID for the association
   type. Association Type.

6.1.4.  Unique Identification for an Association Group

   The combination of the mandatory fields Association type, Type, Association
   ID
   ID, and Association Source in the ASSOCIATION object uniquely identify
   identifies the association group.  If the optional TLVs - Global (Global
   Association Source or and Extended Association ID ID) are included, then
   they MUST be included in combination with mandatory fields to
   uniquely identify the association group.  In this document, all these
   fields are collectively called 'association parameters'. "association parameters".  Note that
   the ASSOCIATION object MAY include other optional TLVs (not defined
   in this document) based on the association types, that provides
   'information' Association Types.  These TLVs provide
   "information" related to the association type, this Association Type.  This document uses the
   term 'association information' for it. refers
   to this information as "association information".

6.2.  Relationship with to the RSVP ASSOCIATION Object

   The format of the PCEP ASSOCIATION Object object defined in this document is
   aligned with the RSVP ASSOCIATION object ([RFC6780]). [RFC6780].  Various
   Association types Types related to RSVP association are defined in
   [RFC4872], [RFC4873], and [RFC7551].  The PCEP extensions that define
   new association types, Association Types should clarify how the PCEP associations would
   work with RSVP associations and vice-versa. vice versa.

6.3.  Object Encoding in PCEP messages Messages

   Message formats in this document are expressed using Reduced Routing BNF
   (RBNF) as used in [RFC5440] and defined in [RFC5511].

6.3.1.  Stateful PCEP messages Messages

   The ASSOCIATION Object object MAY be carried in the Path Computation Update
   (PCUpd), Path Computation Report (PCRpt) PCUpd, PCRpt, and Path
   Computation Initiate (PCInitiate) messages.

   When carried in a PCRpt message, it this object is used to report the
   association group membership pertaining to a an LSP to a stateful PCE.
   The PCRpt message are is used for both initial state synchronization State Synchronization
   operations (Section 5.6 of [RFC8231]) [RFC8231]), as well as whenever the state
   of the LSP changes.  If the LSP belongs to an association group, then
   the associations MUST be included during the state synchronization State Synchronization
   operations.

   The PCRpt message can also be used to remove an LSP from one or more
   association groups by setting the R flag to 1 in the ASSOCIATION
   object.

   When an LSP is first reported to the PCE, the PCRpt message MUST
   include all the association groups that it belongs to.  Any
   subsequent report PCRpt message SHOULD include only the associations that
   are being modified or removed.

   The PCRpt message is defined in [RFC8231] and updated as shown below:

      <PCRpt Message> ::= <Common Header>
                          <state-report-list>

   Where:

         <state-report-list> ::= <state-report>[<state-report-list>]

         <state-report> ::= [<SRP>]
                            <LSP>
                            [<association-list>]
                            <path>

   Where:

         <path>::= <intended-path>
                   [<actual-attribute-list><actual-path>]
                   <intended-attribute-list>

         <association-list> ::= <ASSOCIATION> [<association-list>]

   When an LSP is delegated to a stateful PCE, the stateful PCE can
   create a new association group for this LSP, LSP or associate it with one
   or more existing association groups.  This is done by including the
   ASSOCIATION Object object in a PCUpd message.  A stateful PCE can also
   remove a delegated LSP from one or more association groups by setting
   the R flag to 1 in the ASSOCIATION object.

   The PCUpd message SHOULD include the association groups that are
   being modified or removed, there removed.  There is no need to include associations
   that remains remain unchanged.

   The PCUpd message is defined in [RFC8231] and updated as shown below:

    <PCUpd Message> ::= <Common Header>
                        <update-request-list>

   Where:

       <update-request-list> ::= <update-request>[<update-request-list>]

       <update-request> ::= <SRP>
                            <LSP>
                            [<association-list>]
                            <path>

   Where:

       <path>::= <intended-path><intended-attribute-list>

       <association-list> ::= <ASSOCIATION> [<association-list>]

   Unless a PCEP speaker wants to delete an association from an LSP or
   make changes to the association, it does not need to carry include the
   ASSOCIATION object in future stateful messages.

   A PCE initiating a new LSP can also include the association groups
   that this LSP belongs to.  This is done by including the ASSOCIATION
   Object
   object in a PCInitiate message.  The PCInitiate message MUST include
   all the association groups that it belongs to.  The PCInitiate
   message is defined in [RFC8281] and updated as shown below:

   <PCInitiate Message> ::= <Common Header>
                            <PCE-initiated-lsp-list>

   Where:

   <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
                                [<PCE-initiated-lsp-list>]

   <PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
                                   <PCE-initiated-lsp-deletion>)

   <PCE-initiated-lsp-instantiation> ::= <SRP>
                                         <LSP>
                                         [<END-POINTS>]
                                         <ERO>
                                         [<association-list>]
                                         [<attribute-list>]

   Where:

   <association-list> ::= <ASSOCIATION> [<association-list>]

6.3.2.  Request Message

   In the case of a passive (stateful or stateless) PCE, the ASSOCIATION
   Object
   object is OPTIONAL and MAY be carried in the Path Computation Request
   (PCReq) PCReq message.

   When carried in a PCReq message, the ASSOCIATION Object object is used to
   associate the path computation request to an association group.  The
   association (and the other LSPs) should be known to the PCE
   beforehand.  These could be operator-configured operator configured or dynamically
   learned before beforehand via stateful PCEP messages.  The R flag in the
   ASSOCIATION object within a PCReq message MUST be set to 0 while
   sending and ignored on receipt.

   The PCReq message is defined in [RFC5440] and updated in [RFC8231] ,
   it [RFC8231].
   It is further updated below for association: association groups:

   <PCReq Message>::= <Common Header>
                      [<svec-list>]
                      <request-list>

   Where:

      <svec-list>::= <SVEC>[<svec-list>]
      <request-list>::= <request>[<request-list>]

      <request>::= <RP>
                   <END-POINTS>
                   [<LSP>]
                   [<LSPA>]
                   [<BANDWIDTH>]
                   [<metric-list>]
                   [<association-list>]
                   [<RRO>[<BANDWIDTH>]]
                   [<IRO>]
                   [<LOAD-BALANCING>]

   Where:

      <association-list> ::= <ASSOCIATION> [<association-list>]

   Note that the LSP object MAY be present for the passive stateful PCE
   mode.

6.3.3.  Reply Message

   In the case of a passive (stateful or stateless) PCE, the ASSOCIATION
   Object
   object is OPTIONAL and MAY be carried in the Path Computation Reply
   (PCRep) PCRep message with the
   NO-PATH object.  The ASSOCIATION object in the PCRep message
   indicates the association group that cause caused the PCE to fail to find a
   path.

   The PCRep message is defined in [RFC5440] and updated in [RFC8231] ,
   it [RFC8231].
   It is further updated below for association: association groups:

   <PCRep Message> ::= <Common Header>
                       <response-list>

   Where:

      <response-list>::=<response>[<response-list>]

      <response>::=<RP>
                   [<LSP>]
                   [<NO-PATH>]
                   [<association-list>]
                   [<attribute-list>]
                   [<path-list>]

   Where:

      <association-list> ::= <ASSOCIATION> [<association-list>]

   Note that the LSP object MAY be present for the passive stateful PCE
   mode.

6.4.  Processing Rules

   Association groups can be operator-configured operator configured on the necessary PCEP
   speakers
   speakers, and the PCEP speakers can join the existing association
   groups.  In addition, a PCC or a PCE can create association groups
   dynamically
   dynamically, and the PCEP speaker can also report the associations to
   its peer via PCEP messages.  The operator-configured associations Operator-configured Associations are
   created via configurations (where all association parameters are
   manually set) and exist until explicitly removed via configurations.
   The PCEP speaker can add LSPs to these configured associations and
   carry
   provide this information via stateful PCEP messages.  The dynamic
   associations are created dynamically by the PCEP speaker (where all
   association parameters are populated dynamically).  The association
   group is attached to the LSP state, and the association group exists till
   until there is at least one LSP as part of the association.  As
   described in Section 6.1.4, the association parameters are the
   combination of Association type, Type, Association ID ID, and Association Source
   Source, as well as the optional global source Global Association Source and extended association identifier, that
   Extended Association ID TLVs; this combination uniquely identifies an
   association group.  The information related to the association types Association Types
   encoded via the TLVs of a particular
   association type Association Type (not described
   in this document) are is the association information (Section 6.1.4).

   If a PCEP speaker does not recognize the ASSOCIATION object in the
   stateful message, it will return a PCErr message with Error-Type
   "Unknown Object" as described in [RFC5440].  In the case of a PCReq
   message, the PCE would react based on the P flag as per [RFC5440].
   If a PCEP speaker understands the ASSOCIATION object but does not
   support the Association type, Type, it MUST return a PCErr message with
   Error-Type 26 (Early allocation by IANA) "Association Error" and
   Error-Value Error-value 1 "Association type Type
   is not supported".  If any association parameters are invalid in the
   ASSOCIATION object, the PCEP speaker would consider this as malformed object
   malformed and handle process it as a malformed message [RFC5440].  On
   receiving a PCEP message with
   ASSOCIATION, an ASSOCIATION object, if a PCEP
   speaker finds that too many LSPs belong to the association group, it
   MUST return a PCErr message with Error-Type 26
   (Early allocation by IANA) "Association Error"
   and Error-Value Error-value 2 "Too many LSPs in the association group".  If a
   PCEP speaker cannot handle a new association, it MUST return a PCErr
   message with Error-Type 26
   (Early allocation by IANA) "Association Error" and Error-Value Error-value 3 "Too
   many association groups".  These numbers MAY be set by the operator
   or
   decided chosen based on a local policy.

   If a PCE peer is unwilling or unable to process the ASSOCIATION
   object in the stateful message, it MUST return a PCErr message with
   the Error-Type "Not supported object" and follow the relevant
   procedures described in [RFC5440].  In the case of a PCReq message,
   the PCE would react based on the P flag as per [RFC5440].  On
   receiving a PCEP message with ASSOCIATION, an ASSOCIATION object, if a PCEP
   speaker could not add the LSP to the association group for any
   reason, it MUST return a PCErr message with Error-Type 26 (Early allocation by IANA)
   "Association Error" and Error-Value Error-value 7 "Cannot join the association
   group".

   If a PCEP speaker receives an ASSOCIATION object for an operator- Operator-
   configured association Association and the association identifier Association ID is not in the
   operator-configured association range Operator-
   configured Association Range for the Association type Type and Association
   Source, it MUST return a PCErr message with Error-Type 26
   (Early allocation by IANA)
   "Association Error" and Error-Value Error-value 8 "Association identifier ID not in range".

   If a PCEP speaker receives an ASSOCIATION object in a PCReq message, message
   and the association is not known (association (the association is not configured, or
   was not created dynamically, or was not learned from a PCEP peer), it
   MUST return a PCErr message with Error-Type 26 (Early allocation by IANA) "Association Error"
   and Error-Value Error-value 4 "Association unknown".

   If the association information (related to the association group as a
   whole) received from the peer does not match with the local operator-
   configured information, it MUST return a PCErr message with Error-
   Type 26 (Early allocation by IANA) "Association Error" and Error-
   Value Error-value 5 "Operator-configured
   association information mismatch".  On receiving association
   information (related to the association group as a whole) that does
   not match with the association information previously received about the
   same association from a peer, it MUST return a PCErr message with
   Error-Type 26 (Early allocation by IANA) "Association Error" and Error-Value Error-value 6 "Association
   information mismatch".  Note that information related to each LSP
   within the association as part of the association information TLVs
   could be different.

   If a PCEP speaker receives an ASSOCIATION object with the R bit set
   for removal, removal and the association group (identified by association
   parameters) is not known, it MUST return a PCErr message with Error-
   Type 26 (Early allocation by IANA) "Association Error" and Error-
   Value Error-value 4 "Association unknown".

   The dynamic associations are cleared along with the LSP state
   information as per the [RFC8231].  When a PCEP session is terminated,
   after expiry of the State Timeout Interval at the PCC, the LSP state
   associated with that PCEP session is reverted to operator-defined
   default parameters or behaviours.  Same behaviors.  The same procedure is also followed
   for the association groups.  On session termination at the PCE, when
   the LSP state reported by the PCC is cleared, the association groups
   are also cleared.  When there are no LSPs in an association group,
   the association is considered to be empty and thus deleted.

   In case

   If the LSP is delegated to another PCE on session failure, the
   associations (and association information) set by the PCE remains remain
   intact, unless updated by the new PCE that takes over.

   Upon LSP delegation revocation, the PCC MAY clear the association
   created by the PCE, but in order to avoid traffic loss, it SHOULD
   perform this action in a make-before-break fashion (same as
   [RFC8231]).

7.  IANA Considerations

   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
   registry at <http://www.iana.org/assignments/pcep>. <https://www.iana.org/assignments/pcep>.

7.1.  PCEP Object

   The "PCEP "Path Computation Element Protocol (PCEP) Numbers" registry
   contains a subregistry called "PCEP Objects".  IANA is requested to confirm the early allocation of has allocated the
   following code point in the PCEP Objects "PCEP Objects" registry.

      +--------------------+-------------+-------------+-----------+
      | Object-Class Value | Name        | Object-Type | Reference |
      +====================+=============+=============+===========+
      | 40 (Early allocation by Association                        [This.I-D]
            IANA)
                           Object-Type                 | ASSOCIATION | 0: Reserved | RFC 8697  |
      |                    |             +-------------+-----------+
      |                    |             | 1: IPv4     | RFC 8697  |
      |                    |             +-------------+-----------+
      |                    |             | 2: IPv6     | RFC 8697  |
      +--------------------+-------------+-------------+-----------+

                           Table 1: PCEP Object

7.2.  PCEP TLV

   IANA is requested to confirm the early allocation of has allocated the following code point points in the "PCEP TLV Type
   Indicators" registry.

       +-------+---------------------------------------+-----------+
       | Value | Meaning                               | Reference |
       +=======+=======================================+===========+
       | 29 (Early    | Operator-configured         [This.I-D]
           allocation by Association Range
               IANA) | RFC 8697  |
       +-------+---------------------------------------+-----------+
       | 30 (Early    | Global Association Source   [This.I-D]
           allocation by
               IANA)             | RFC 8697  |
       +-------+---------------------------------------+-----------+
       | 31 (Early    | Extended Association ID     [This.I-D]
           allocation by
               IANA)               | RFC 8697  |
       +-------+---------------------------------------+-----------+

                     Table 2: PCEP TLV Type Indicators

   IANA is requested to fix has corrected the capitalization in the meaning for value 31 in
   the above registry to 'Extended "Extended Association ID', ID"; it is currently mentioned was previously
   listed as
   'Extended "Extended Association Id'. Id".

   IANA is also requested to make has made a new assignment for in the existing "PCEP TLV Type
   Indicators" registry as follows:

                  +-------+-----------------+-----------+
                  | Value | Meaning         | Reference
                TBD |
                  +=======+=================+===========+
                  | 35    | ASSOC-Type-List             [This.I-D] | RFC 8697  |
                  +-------+-----------------+-----------+

                     Table 3: ASSOC-Type-List PCEP TLV
                               Type Indicator

7.3.  Association Flags

   This document requests

   Per this document, IANA to create has created a subregistry of the "PCEP "Path
   Computation Element Protocol (PCEP) Numbers" registry for the bits
   carried in the Flags field of the ASSOCIATION object.  The
   subregistry is called "ASSOCIATION Flags Flag Field".  New values are
   assigned by Standards Action [RFC8126].  Each bit should
   be is tracked with the
   following qualities:

   o

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

   o

   *  Capability description

   o

   *  Defining RFC

                     +-----+-------------+-----------+
                     | Bit | Description | Reference |
                     +=====+=============+===========+
                     | 15  | R (Removal)                        [This.I-D] | RFC 8697  |
                     +-----+-------------+-----------+

                       Table 4: New ASSOCIATION Flag
                                   Field

7.4.  Association Type

   This document requests

   Per this document, IANA to create has created a subregistry of the "PCEP "Path
   Computation Element Protocol (PCEP) Numbers" registry for the
   Association Type field of the the ASSOCIATION object.  The subregistry is
   called "ASSOCIATION Type Field".  New values are to be assigned by
   Standards Action [RFC8126].  Each value
   should be is tracked with the following
   qualities:

   o

   *  Type

   o

   *  Name

   o

   *  Reference

   There

                      +------+----------+-----------+
                      | Type | Name     | Reference |
                      +======+==========+===========+
                      | 0    | Reserved | RFC 8697  |
                      +------+----------+-----------+

                          Table 5: New ASSOCIATION
                                 Type Field

   Values 2-65535 are no association types specified in this document, future Unassigned.  Future documents should request the
   assignment of association types Association Types from this subregistry.

7.5.  PCEP-Error Object

   IANA is requested to confirm the early allocation of has allocated the following code points within the "PCEP-ERROR
   Object Error Types and Values"
   sub-registry subregistry of the "PCEP "Path Computation
   Element Protocol (PCEP) Numbers" registry, registry as follows:

     +------------+-------------+------------------------+-----------+
     | Error-Type | Meaning     | Error-value            | Reference |
     +============+=============+========================+===========+
     | 26         | Association Error [This.I-D]
       (early      Error-value=0:
       alloc by | 0: Unassigned
       IANA)       Error-value=1:          | RFC 8697  |
     |            | Error       +------------------------+-----------+
     |            |             | 1: Association type Type is | RFC 8697  |
     |            |             | not supported
                   Error-value=2:          |           |
     |            |             +------------------------+-----------+
     |            |             | 2: Too many LSPs in    | RFC 8697  |
     |            |             | the association group
                   Error-value=3:  |           |
     |            |             +------------------------+-----------+
     |            |             | 3: Too many            | RFC 8697  |
     |            |             | association groups
                   Error-value=4:     |           |
     |            |             +------------------------+-----------+
     |            |             | 4: Association unknown
                   Error-value=5: | RFC 8697  |
     |            |             +------------------------+-----------+
     |            |             | 5: Operator-configured | RFC 8697  |
     |            |             | association            |           |
     |            |             | information mismatch
                   Error-value=6:   |           |
     |            |             +------------------------+-----------+
     |            |             | 6: Association         | RFC 8697  |
     |            |             | information mismatch
                   Error-value=7:   |           |
     |            |             +------------------------+-----------+
     |            |             | 7: Cannot join the     | RFC 8697  |
     |            |             | association group
                   Error-value=8:      |           |
     |            |             +------------------------+-----------+
     |            |             | 8: Association identifier ID not  | RFC 8697  |
     |            |             | in range               |           |
     +------------+-------------+------------------------+-----------+

                    Table 6: PCEP-ERROR Types and Names

8.  Security Considerations

   The security considerations described in [RFC8231] and [RFC5440]
   apply to the extensions described in this document as well.
   Additional considerations related to a malicious PCEP speaker are
   introduced, as associations could be spoofed and could be used as an
   attack vector.  An attacker could attempt to create too many
   associations in an attempt to load the PCEP peer.  The PCEP peer
   responds with a PCErr message as described in Section 6.4.  An
   attacker could impact LSP operations by creating bogus associations.
   Further, association groups could provides provide an adversary with the
   opportunity to eavesdrop on the relationship between the LSPs.  Thus  Thus,
   securing the PCEP session using Transport Layer Security (TLS)
   [RFC8253], as per the recommendations and best current practices in
   [RFC7525], is RECOMMENDED.

   Much of the information carried in the ASSOCIATION object, object as per this
   document is not extra sensitive.  It often reflects information that
   can also be derived from the LSP Database, database, but the association
   provides a much easier grouping of related LSPs and messages.
   Implementations and operator can operators can, and should should, use indirect values in
   the ASSOCIATION object as a way to hide any sensitive business
   relationships.

9.  Manageability Considerations

   All manageability requirements and considerations listed in [RFC5440]
   and [RFC8231] apply to PCEP protocol extensions defined in this
   document.  In addition, requirements and considerations listed in
   this section apply.

9.1.  Control of Function and Policy

   A PCE or PCC implementation MUST allow operator-configured
   associations Operator-configured
   Associations and SHOULD allow the setting of the operator-configured
   association range Operator-configured
   Association Range (Section 3.4) as described in this document.

9.2.  Information and Data Models

   The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. [PCEP-YANG].  In the future, this
   YANG module should be extended or augmented to provide the following
   additional information relating related to association groups.

   An implementation SHOULD allow the operator to view the associations
   configured or created dynamically.  Further implementation  Future implementations SHOULD
   allow to view the viewing of associations reported by each peer, peer and the
   current set of LSPs in the association.

   It might also be useful to find out how many associations for each
   association type
   Association Type currently exist and to know how many free
   association identifiers
   Association IDs are available for a particular association
   type Association Type and
   source.

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

9.4.  Verify  Verifying Correct Operations Operation

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

9.5.  Requirements on Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

9.6.  Impact on Network Operations

   Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP
   extensions defined in this document.

12.

10.  References

12.1.

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

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

   [RFC6780]  Berger, L., Le Faucheur, F., and A. Narayanan, "RSVP
              ASSOCIATION Object Extensions", RFC 6780,
              DOI 10.17487/RFC6780, October 2012,
              <https://www.rfc-editor.org/info/rfc6780>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.

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

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

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

12.2.

10.2.  Informative References

   [RFC4657]  Ash, J., Ed. and J. J.L. 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>.

   [RFC4872]  Lang, J., J.P., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
              Ed., "RSVP-TE Extensions in Support of End-to-End
              Generalized Multi-Protocol Label Switching (GMPLS)
              Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
              <https://www.rfc-editor.org/info/rfc4872>.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
              "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
              May 2007, <https://www.rfc-editor.org/info/rfc4873>.

   [RFC6007]  Nishioka, I. and D. King, "Use of the Synchronization
              VECtor (SVEC) List for Synchronized Dependent Path
              Computations", RFC 6007, DOI 10.17487/RFC6007, September
              2010, <https://www.rfc-editor.org/info/rfc6007>.

   [RFC7551]  Zhang, F., Ed., Jing, R., and R. Gandhi, Ed., "RSVP-TE
              Extensions for Associated Bidirectional Label Switched
              Paths (LSPs)", RFC 7551, DOI 10.17487/RFC7551, May 2015,
              <https://www.rfc-editor.org/info/rfc7551>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [I-D.ietf-pce-pcep-yang]

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

   [I-D.ietf-pce-stateful-path-protection] Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-13, 31 October
              2019,
              <https://tools.ietf.org/html/draft-ietf-pce-pcep-yang-13>.

   [PCE-PROTECTION]
              Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I.,
              and M. Negi, "PCEP Extensions for Associating Working and
              Protection LSPs with Stateful PCE", draft-ietf-pce-
              stateful-path-protection-07 (work Work in progress), June 2019.

   [I-D.ietf-pce-association-diversity] Progress,
              Internet-Draft, draft-ietf-pce-stateful-path-protection-
              11, 25 September 2019, <https://tools.ietf.org/html/draft-
              ietf-pce-stateful-path-protection-11>.

   [PCE-DIVERSITY]
              Litkowski, S., Sivabalan, S., Barth, C., and M. Negi,
              "Path Computation Element Communication Protocol (PCEP)
              Extension for LSP Diversity Constraint Signaling", draft-
              ietf-pce-association-diversity-08 (work in progress), July
              2019. Work in
              Progress, Internet-Draft, draft-ietf-pce-association-
              diversity-13, 18 December 2019,
              <https://tools.ietf.org/html/draft-ietf-pce-association-
              diversity-13>.

Appendix A.  Example for Operator-configured of an Operator-Configured Association Range

   Consider an association type Association Type T1 (which allows both dynamic and
   operator-configured association
   Operator-configured Associations with a default range of <0x1000,
   0xffff>).  Consider that, because of need the needs of the network, the
   PCE needs to create more dynamic associations and would like to
   change the association range Association Range to <0xbffe, 0xffff> instead.  During
   PCEP session establishment establishment, the PCE would advertise the new range, the range.
   The PCC could skip advertising advertising, as the default values are used.  If a
   PCC is creating a dynamic association (with the PCC as association source) the
   Association Source), it needs to pick a free association identifier Association ID for type
   T1 in the range
   of <0x1, 0x0fff> 0x0fff>, whereas if a PCE is creating a dynamic
   association (with the PCE as association source) the Association Source), it needs to
   pick a free association
   identifier Association ID from the range <0x1, 0xbffd>.  Similarly  Similarly,
   if an operator-
   configured association Operator-configured Association is manually configured with the
   PCC as
   association source, the Association Source, it should be from the range <0x1000, 0xffff>
   0xffff>, whereas if the PCE is association source, the Association Source, it should be
   from the range <0xbffe, 0xffff>.  In case  If the association source Association Source is not a
   PCEP peer (for
   example example, an NMS system), NMS), then the default range of <0x1000,
   0xffff> is considered.

10.

Acknowledgments

   We would like to thank Yuji Kamite and Joshua George for their
   contributions to this document.  Also thanks  Thanks also to Venugopal Reddy,
   Cyril Margaria, Rakesh Gandhi, Mike Koldychev, and Adrian Farrel for
   their useful comments.

   We would like to thank Julien Meuric for shepherding this document
   and providing comments with text suggestions.

   Thanks to Stig Venaas for the RTGDIR review comments.

   Thanks to Alvaro Retana, Mirja Kuhlewind, Kühlewind, Martin Vigoureux, Barry
   Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG
   comments.

11.

Contributors

   Stephane Litkowski
   Orange

   Email: stephane.litkowski@orange.com

   Xian Zhang
   Huawei Technologies
   F3-1-B RnD Center, Huawei Base
   Bantian, Longgang District
   Shenzhen
   Shenzhen, 518129
   China

   Email: zhang.xian@huawei.com

   Mustapha Aissaoui
   Nokia

   Email: mustapha.aissaoui@nokia.com

Authors' Addresses

   Ina Minei
   Google, Inc.
   1600 Amphitheatre Parkway
   Mountain View, CA 94043
   US
   United States of America

   Email: inaminei@google.com

   Edward Crabbe
   Individual Contributor

   Email: edward.crabbe@gmail.com

   Siva Sivabalan
   Cisco Systems, Inc.
   170 West Tasman Dr.
   San Jose, CA 95134
   US
   United States of America

   Email: msiva@cisco.com

   Hariharan Ananthakrishnan
   Netflix

   Email: hari@netflix.com

   Dhruv Dhody
   Huawei
   Divyashree Techno Park, Whitefield
   Bangalore, KA
   Bangalore 560066
   KA
   India

   Email: dhruv.ietf@gmail.com

   Yosuke Tanaka
   NTT Communications Corporation
   Granpark Tower 3-4-1 Shibaura, Minato-ku Minato-ku, Tokyo
   108-8118
   Japan

   Email: yosuke.tanaka@ntt.com