doc: Add RFC documents

1 files changed, 1414 insertions, 0 deletions

diff --git a/doc/rfc/rfc8697.txt b/doc/rfc/rfc8697.txt
new file mode 100644
index 0000000..fde0e5e
--- /dev/null
+++ b/doc/rfc/rfc8697.txt
@@ -0,0 +1,1414 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                          I. Minei
+Request for Comments: 8697                                  Google, Inc.
+Category: Standards Track                                      E. Crabbe
+ISSN: 2070-1721                                   Individual Contributor
+                                                            S. Sivabalan
+                                                     Cisco Systems, Inc.
+                                                      H. Ananthakrishnan
+                                                                 Netflix
+                                                                D. Dhody
+                                                                  Huawei
+                                                               Y. Tanaka
+                                          NTT Communications Corporation
+                                                            January 2020
+
+
+ Path Computation Element Communication Protocol (PCEP) Extensions for
+ Establishing Relationships between Sets of Label Switched Paths (LSPs)
+
+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 behaviors), and it is equally
+   applicable to the stateful PCE (active and passive modes) and the
+   stateless PCE.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for 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 this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8697.
+
+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
+     1.1.  Requirements Language
+   2.  Terminology
+   3.  Architectural Overview
+     3.1.  Motivations
+     3.2.  Relationship to the SVEC List
+     3.3.  Operational Overview
+     3.4.  Operator-Configured Association Range
+   4.  Discovery of Supported Association Types
+     4.1.  ASSOC-Type-List TLV
+       4.1.1.  Procedure
+   5.  Operator-Configured Association Range TLV
+     5.1.  Procedure
+   6.  ASSOCIATION Object
+     6.1.  Object Definition
+       6.1.1.  Global Association Source TLV
+       6.1.2.  Extended Association ID TLV
+       6.1.3.  Association Source
+       6.1.4.  Unique Identification for an Association Group
+     6.2.  Relationship to the RSVP ASSOCIATION Object
+     6.3.  Object Encoding in PCEP Messages
+       6.3.1.  Stateful PCEP Messages
+       6.3.2.  Request Message
+       6.3.3.  Reply Message
+     6.4.  Processing Rules
+   7.  IANA Considerations
+     7.1.  PCEP Object
+     7.2.  PCEP TLV
+     7.3.  Association Flags
+     7.4.  Association Type
+     7.5.  PCEP-Error Object
+   8.  Security Considerations
+   9.  Manageability Considerations
+     9.1.  Control of Function and Policy
+     9.2.  Information and Data Models
+     9.3.  Liveness Detection and Monitoring
+     9.4.  Verifying Correct Operation
+     9.5.  Requirements on Other Protocols
+     9.6.  Impact on Network Operations
+   10. References
+     10.1.  Normative References
+     10.2.  Informative References
+   Appendix A.  Example of an Operator-Configured Association Range
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC5440] describes the Path Computation Element (PCE) Communication
+   Protocol (PCEP).  PCEP enables 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
+   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 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.  [RFC6780]
+   describes how the ASSOCIATION object can be more generally applied by
+   defining the Extended ASSOCIATION 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 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 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
+
+   *  PCEP Peer
+
+   *  Path Computation Request (PCReq)
+
+   *  Path Computation Reply (PCRep)
+
+   *  PCEP Error (PCErr)
+
+   This document uses the following terms defined in [RFC8051]:
+
+   *  Stateful PCE
+
+   *  Active Stateful PCE
+
+   *  Passive Stateful PCE
+
+   *  Delegation
+
+   This document uses the following terms defined in [RFC8231]:
+
+   *  LSP State Report (PCRpt)
+
+   *  LSP Update Request (PCUpd)
+
+   *  State Timeout Interval
+
+   This document uses the following terms defined in [RFC8281]:
+
+   *  PCE-initiated LSP
+
+   *  LSP Initiate Request (PCInitiate)
+
+3.  Architectural Overview
+
+3.1.  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.  For example, to support PCE-
+   controlled make-before-break, an association between the original
+   path and the reoptimized path is desired.  Similarly, for end-to-end
+   protection, an association between working and protection LSPs is
+   required (see [PCE-PROTECTION]).  For diverse paths, an association
+   between a group of LSPs could be used (see [PCE-DIVERSITY]).  Another
+   use for an LSP grouping would be to apply a common set of
+   configuration parameters or behaviors to a set of LSPs.
+
+   For a stateless PCE, it might be useful to associate a PCReq message
+   to an association group, thus enabling it to associate a common set
+   of policies, configuration parameters, or 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 where the LSP could join an
+   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 to the SVEC List
+
+   Note that [RFC5440] defines a mechanism for the synchronization of a
+   set of PCReq messages by using the SVEC (Synchronization VECtor)
+   object, which specifies the list of synchronized requests that can be
+   either dependent or independent.  The SVEC object identifies the
+   relationship between the set of PCReq messages, identified by
+   "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, and it describes a
+   number of usage scenarios for SVEC lists within single-domain and
+   multi-domain environments.
+
+   The 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 should
+   clarify the relationship between the SVEC object and the Association
+   Type, if any.
+
+3.3.  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 headend or different headends.
+
+   Some associations could be created dynamically by a PCEP 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 in question, a PCEP speaker could then
+   ask an LSP to join the Operator-configured Association.  Usage of
+   dynamic and configured associations is usually dependent on the type
+   of association.
+
+   For Operator-configured Associations, the association parameters,
+   such as the Association Identifier (Association ID), Association
+   Type, and the Association Source IP address, are manually configured
+   by the operator.  In the case of a dynamic association, the
+   association parameters, such as the Association ID, are allocated
+   dynamically by the PCEP speaker.  The Association Source is set as
+   the local PCEP speaker address unless local policy dictates
+   otherwise, in which case 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 is known to the PCEP peer beforehand,
+   a PCEP peer could ask an LSP to join the 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 cleanup MUST also take care of associations.
+
+   Multiple types of associations can exist, each with its own
+   Association ID space.  The definition of the different Association
+   Types and their behaviors is outside the scope of this document.  The
+   establishment and removal of the association relationship can be done
+   on a per-LSP basis.  An LSP may join multiple association groups that
+   have the same Association Type or different Association Types.
+
+3.4.  Operator-Configured Association Range
+
+   Some Association Types are dynamic, some are operator configured, and
+   some could be both.  For the Association Types that could be both
+   dynamic and operator configured and use the same Association Source,
+   it is necessary to distinguish a range of Association IDs that are
+   marked for Operator-configured Associations, to avoid any Association
+   ID clashes within the scope of the Association Source.  This document
+   assumes that these two ranges are configured.
+
+   A range of Association IDs for each Association Type (and Association
+   Source) is kept for the Operator-configured Associations.  Dynamic
+   associations MUST NOT use the Association ID from this range.
+
+   This range, as set at the PCEP speaker (a PCC or PCE, as an
+   Association Source), needs to be communicated to a PCEP peer in the
+   Open message.  A new TLV is defined in this specification for this
+   purpose (Section 5).  See Appendix A for an example.
+
+   The Association ID range for sources other than the PCEP speaker (for
+   example, a Network Management System (NMS)) is not communicated in
+   PCEP, and the procedure for 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 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.
+
+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.
+
+   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 8 octets).
+
+   The PCEP ASSOC-Type-List TLV has the following format:
+
+      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 #1        |      Assoc-Type #2            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     //                                                             //
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |          Assoc-Type #N        |       padding                 |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                  Figure 1: The ASSOC-Type-List TLV Format
+
+   Type:  35
+
+   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.
+
+   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.  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 1 and 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 (to be defined in future documents) can specify
+   if the Association Type advertisement is mandatory for it.  Thus, the
+   ASSOC-Type-List TLV MUST be included if at least one mandatory
+   Association Type needs to be advertised, and the ASSOC-Type-List TLV
+   MAY be included otherwise.  For an Association Type that specifies
+   that the advertisement is mandatory, a missing 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 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 in the list of supported
+   Association Types (rather than an indication that the Association
+   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.
+
+   If the use of the ASSOC-Type-List TLV is triggered by support for a
+   mandatory Association Type, then it is RECOMMENDED that the PCEP
+   implementation include all supported Association Types (including
+   optional types) to ease the operations of the PCEP peer.
+
+5.  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 by the PCEP speaker (as an Association 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 Association Range for an 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:
+
+      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 #1        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Start-Assoc-ID #1        |           Range #1            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     //                                                             //
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |             Reserved          |          Assoc-Type #N        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |      Start-Assoc-ID #N        |           Range #N            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 2: The OP-CONF-ASSOC-RANGE TLV Format
+
+   Type:  29
+
+   Length:  N * 8 (where N is the number of Association Types).
+
+   Value:  Includes the following fields, repeated for each Association
+      Type:
+
+      Reserved (2 bytes):  MUST be set to 0 on transmission and MUST be
+         ignored on receipt.
+
+      Assoc-Type (2 bytes):  The Association Type (Section 7.4).  The
+         Association Types will be defined in future documents.
+
+      Start-Assoc-ID (2 bytes):  The "start association" identifier for
+         the Operator-configured Association Range for the particular
+         Association Type.  The values 0 and 0xffff MUST NOT be used; on
+         receipt of these values in the TLV, the session is rejected,
+         and an error message is sent (see Section 5.1).
+
+      Range (2 bytes):  The number of associations marked for the
+         Operator-configured Associations.  Range MUST be greater than
+         0, and it MUST be such that (Start-Assoc-ID + Range) does not
+         cross the largest Association ID value of 0xffff.  If this
+         condition is not satisfied, the session is 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.
+   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 1 and 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 that could be both dynamic and operator configured.
+   For Association Types that are only dynamic or only operator
+   configured, this TLV MAY be skipped, in which case the full range of
+   Association IDs is considered dynamic or operator configured,
+   respectively.  Each Association Type (to be defined in future
+   documents) can specify the default value for 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 applies.  If the Association
+   Source is not a PCEP speaker, the default value for the Operator-
+   configured Association Range is used for the Association Source.
+
+   If the Assoc-Type is not recognized or supported by the PCEP speaker,
+   it MUST ignore that respective (Start-Assoc-ID + Range).  If the
+   Assoc-Type is recognized/supported but Start-Assoc-ID or Range is set
+   incorrectly, the PCEP session MUST be rejected with Error-Type 1 and
+   Error-value 1 (PCEP session establishment failure / Reception of an
+   invalid Open message).  The incorrect range includes the case when
+   the (Start-Assoc-ID + Range) crosses the largest Association ID value
+   of 0xffff.
+
+   A given 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
+   send overlapping ranges for an Association Type.  If a PCEP peer
+   receives overlapping ranges for an Association Type, it MUST consider
+   the Open message malformed and MUST reject the PCEP session with
+   Error-Type 1 and Error-value 1 (PCEP session establishment failure /
+   Reception of an invalid Open message).
+
+   There may be cases where an Operator-configured Association was
+   configured with association parameters (such as an Association ID,
+   Association Type, and Association Source) at the local PCEP speaker,
+   and the PCEP session is later established with the 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 range (by
+   disassociating any LSPs that are part of it (and notifying the PCEP
+   peer of this change)).  If a PCEP speaker receives an association for
+   an Operator-configured Association and the Association ID is not in
+   the Operator-configured Association Range for the Association Type
+   and 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.
+
+   The ASSOCIATION Object-Type value is 1 for 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         |      Association ID           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |              IPv4 Association Source                          |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     //                   Optional TLVs                             //
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 3: The IPv4 ASSOCIATION Object Format
+
+   The ASSOCIATION Object-Type value is 2 for 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         |      Association ID           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     |                    IPv6 Association Source                    |
+     |                                                               |
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     //                   Optional TLVs                             //
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 4: The IPv6 ASSOCIATION Object Format
+
+   Reserved (2 bytes):  MUST be set to 0 and ignored upon receipt.
+
+   Flags (2 bytes):  The following flag is currently defined:
+
+      R (Removal - 1 bit):  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 Path Computation Report (PCRpt) and
+         Path Computation Update (PCUpd) messages.  It is ignored in
+         other PCEP messages.
+
+   The unassigned flags MUST be set to 0 on transmission and MUST be
+   ignored on receipt.
+
+   Association Type (2 bytes):  The Association Type (Section 7.4).  The
+      Association Types will be defined in future documents.
+
+   Association ID (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 the Association
+      Type and 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 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.  The meaning and usage of the Global Association
+   Source 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
+
+   Type:  30
+
+   Length:  Fixed value of 4 bytes.
+
+   Global Association Source:  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.  The meaning and usage of the Extended
+   Association ID 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
+
+   Type:  31
+
+   Length:  Variable.
+
+   Extended Association ID:  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 originated the
+   association.  In the case of dynamic associations, the Association
+   Source is usually set as the local PCEP speaker address unless local
+   policy dictates otherwise, in which case 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 that identifies
+   all instances of the PCE.  In the case of Operator-configured
+   Associations, the Association Source is manually configured, and it
+   could be set as one of the PCEP speakers, an NMS, or any other valid
+   IP address that scopes the Association ID for the Association Type.
+
+6.1.4.  Unique Identification for an Association Group
+
+   The combination of the mandatory fields Association Type, Association
+   ID, and Association Source in the ASSOCIATION object uniquely
+   identifies the association group.  If the optional TLVs (Global
+   Association Source and Extended Association 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".  Note that
+   the ASSOCIATION object MAY include other optional TLVs (not defined
+   in this document) based on the Association Types.  These TLVs provide
+   "information" related to the Association Type.  This document refers
+   to this information as "association information".
+
+6.2.  Relationship to the RSVP ASSOCIATION Object
+
+   The format of the PCEP ASSOCIATION object defined in this document is
+   aligned with the RSVP ASSOCIATION object [RFC6780].  Various
+   Association Types related to RSVP association are defined in
+   [RFC4872], [RFC4873], and [RFC7551].  The PCEP extensions that define
+   new Association Types should clarify how the PCEP associations would
+   work with RSVP associations and vice versa.
+
+6.3.  Object Encoding in PCEP Messages
+
+   Message formats in this document are expressed using Routing BNF
+   (RBNF) as used in [RFC5440] and defined in [RFC5511].
+
+6.3.1.  Stateful PCEP Messages
+
+   The ASSOCIATION object MAY be carried in the PCUpd, PCRpt, and Path
+   Computation Initiate (PCInitiate) messages.
+
+   When carried in a PCRpt message, this object is used to report the
+   association group membership pertaining to an LSP to a stateful PCE.
+   The PCRpt message is used for initial State Synchronization
+   operations (Section 5.6 of [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
+   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 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 or associate it with one
+   or more existing association groups.  This is done by including the
+   ASSOCIATION 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 is no need to include associations
+   that 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 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 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 is OPTIONAL and MAY be carried in the PCReq message.
+
+   When carried in a PCReq message, the ASSOCIATION 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 or dynamically
+   learned 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 is further updated below for 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 is OPTIONAL and MAY be carried in the PCRep message with the
+   NO-PATH object.  The ASSOCIATION object in the PCRep message
+   indicates the association group that caused the PCE to fail to find a
+   path.
+
+   The PCRep message is defined in [RFC5440] and updated in [RFC8231].
+   It is further updated below for 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 on the necessary PCEP
+   speakers, and the PCEP speakers can join the existing association
+   groups.  In addition, a PCC or a PCE can create association groups
+   dynamically, and the PCEP speaker can also report the associations to
+   its peer via PCEP messages.  The 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
+   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
+   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, Association ID, and Association
+   Source, as well as the optional Global Association Source and
+   Extended Association ID TLVs; this combination uniquely identifies an
+   association group.  The information related to the Association Types
+   encoded via the TLVs of a particular Association Type (not described
+   in this document) 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, it MUST return a PCErr message with
+   Error-Type 26 "Association Error" and Error-value 1 "Association Type
+   is not supported".  If any association parameters are invalid in the
+   ASSOCIATION object, the PCEP speaker would consider this object
+   malformed and process it as a malformed message [RFC5440].  On
+   receiving a PCEP message with 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 "Association Error"
+   and 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 "Association Error" and Error-value 3 "Too
+   many association groups".  These numbers MAY be set by the operator
+   or 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 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
+   "Association Error" and Error-value 7 "Cannot join the association
+   group".
+
+   If a PCEP speaker receives an ASSOCIATION object for an Operator-
+   configured Association and the Association ID is not in the Operator-
+   configured Association Range for the Association Type and Association
+   Source, it MUST return a PCErr message with Error-Type 26
+   "Association Error" and Error-value 8 "Association ID not in range".
+
+   If a PCEP speaker receives an ASSOCIATION object in a PCReq message
+   and the association is not known (the association is not configured,
+   was not created dynamically, or was not learned from a PCEP peer), it
+   MUST return a PCErr message with Error-Type 26 "Association Error"
+   and Error-value 4 "Association unknown".
+
+   If the association information (related to the association group as a
+   whole) received from the peer does not match the local operator-
+   configured information, it MUST return a PCErr message with Error-
+   Type 26 "Association Error" and Error-value 5 "Operator-configured
+   association information mismatch".  On receiving association
+   information (related to the association group as a whole) that does
+   not match the association information previously received about the
+   same association from a peer, it MUST return a PCErr message with
+   Error-Type 26 "Association Error" and 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 and the association group (identified by association
+   parameters) is not known, it MUST return a PCErr message with Error-
+   Type 26 "Association Error" and Error-value 4 "Association unknown".
+
+   The dynamic associations are cleared along with the LSP state
+   information as per [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 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 empty and thus deleted.
+
+   If the LSP is delegated to another PCE on session failure, the
+   associations (and association information) set by the PCE 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 <https://www.iana.org/assignments/pcep>.
+
+7.1.  PCEP Object
+
+   The "Path Computation Element Protocol (PCEP) Numbers" registry
+   contains a subregistry called "PCEP Objects".  IANA has allocated the
+   following code point in the "PCEP Objects" registry.
+
+      +--------------------+-------------+-------------+-----------+
+      | Object-Class Value | Name        | Object-Type | Reference |
+      +====================+=============+=============+===========+
+      | 40                 | ASSOCIATION | 0: Reserved | RFC 8697  |
+      |                    |             +-------------+-----------+
+      |                    |             | 1: IPv4     | RFC 8697  |
+      |                    |             +-------------+-----------+
+      |                    |             | 2: IPv6     | RFC 8697  |
+      +--------------------+-------------+-------------+-----------+
+
+                           Table 1: PCEP Object
+
+7.2.  PCEP TLV
+
+   IANA has allocated the following code points in the "PCEP TLV Type
+   Indicators" registry.
+
+       +-------+---------------------------------------+-----------+
+       | Value | Meaning                               | Reference |
+       +=======+=======================================+===========+
+       | 29    | Operator-configured Association Range | RFC 8697  |
+       +-------+---------------------------------------+-----------+
+       | 30    | Global Association Source             | RFC 8697  |
+       +-------+---------------------------------------+-----------+
+       | 31    | Extended Association ID               | RFC 8697  |
+       +-------+---------------------------------------+-----------+
+
+                     Table 2: PCEP TLV Type Indicators
+
+   IANA has corrected the capitalization in the meaning for value 31 in
+   the above registry to "Extended Association ID"; it was previously
+   listed as "Extended Association Id".
+
+   IANA has made a new assignment in the existing "PCEP TLV Type
+   Indicators" registry as follows:
+
+                  +-------+-----------------+-----------+
+                  | Value | Meaning         | Reference |
+                  +=======+=================+===========+
+                  | 35    | ASSOC-Type-List | RFC 8697  |
+                  +-------+-----------------+-----------+
+
+                     Table 3: ASSOC-Type-List PCEP TLV
+                               Type Indicator
+
+7.3.  Association Flags
+
+   Per this document, IANA has created a subregistry of the "Path
+   Computation Element Protocol (PCEP) Numbers" registry for the bits
+   carried in the Flags field of the ASSOCIATION object.  The
+   subregistry is called "ASSOCIATION Flag Field".  New values are
+   assigned by Standards Action [RFC8126].  Each bit is tracked with the
+   following qualities:
+
+   *  Bit number (counting from bit 0 as the most significant bit)
+
+   *  Capability description
+
+   *  Defining RFC
+
+                     +-----+-------------+-----------+
+                     | Bit | Description | Reference |
+                     +=====+=============+===========+
+                     | 15  | R (Removal) | RFC 8697  |
+                     +-----+-------------+-----------+
+
+                       Table 4: New ASSOCIATION Flag
+                                   Field
+
+7.4.  Association Type
+
+   Per this document, IANA has created a subregistry of the "Path
+   Computation Element Protocol (PCEP) Numbers" registry for the
+   Association Type field of the ASSOCIATION object.  The subregistry is
+   called "ASSOCIATION Type Field".  New values are assigned by
+   Standards Action [RFC8126].  Each value is tracked with the following
+   qualities:
+
+   *  Type
+
+   *  Name
+
+   *  Reference
+
+                      +------+----------+-----------+
+                      | Type | Name     | Reference |
+                      +======+==========+===========+
+                      | 0    | Reserved | RFC 8697  |
+                      +------+----------+-----------+
+
+                          Table 5: New ASSOCIATION
+                                 Type Field
+
+   Values 2-65535 are Unassigned.  Future documents should request the
+   assignment of Association Types from this subregistry.
+
+7.5.  PCEP-Error Object
+
+   IANA has allocated the following code points within the "PCEP-ERROR
+   Object Error Types and Values" subregistry of the "Path Computation
+   Element Protocol (PCEP) Numbers" registry as follows:
+
+     +------------+-------------+------------------------+-----------+
+     | Error-Type | Meaning     | Error-value            | Reference |
+     +============+=============+========================+===========+
+     | 26         | Association | 0: Unassigned          | RFC 8697  |
+     |            | Error       +------------------------+-----------+
+     |            |             | 1: Association Type is | RFC 8697  |
+     |            |             | not supported          |           |
+     |            |             +------------------------+-----------+
+     |            |             | 2: Too many LSPs in    | RFC 8697  |
+     |            |             | the association group  |           |
+     |            |             +------------------------+-----------+
+     |            |             | 3: Too many            | RFC 8697  |
+     |            |             | association groups     |           |
+     |            |             +------------------------+-----------+
+     |            |             | 4: Association unknown | RFC 8697  |
+     |            |             +------------------------+-----------+
+     |            |             | 5: Operator-configured | RFC 8697  |
+     |            |             | association            |           |
+     |            |             | information mismatch   |           |
+     |            |             +------------------------+-----------+
+     |            |             | 6: Association         | RFC 8697  |
+     |            |             | information mismatch   |           |
+     |            |             +------------------------+-----------+
+     |            |             | 7: Cannot join the     | RFC 8697  |
+     |            |             | association group      |           |
+     |            |             +------------------------+-----------+
+     |            |             | 8: Association 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 provide an adversary with the
+   opportunity to eavesdrop on the relationship between the LSPs.  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 as per this
+   document is not extra sensitive.  It often reflects information that
+   can also be derived from the LSP database, but the association
+   provides a much easier grouping of related LSPs and messages.
+   Implementations and operators can, and 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 and SHOULD allow the setting of the 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 [PCEP-YANG].  In the future, this
+   YANG module should be extended or augmented to provide the following
+   additional information related to association groups.
+
+   An implementation SHOULD allow the operator to view the associations
+   configured or created dynamically.  Future implementations SHOULD
+   allow the viewing of associations reported by each 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 currently exist and to know how many free
+   Association IDs are available for a particular 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.  Verifying Correct 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.
+
+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>.
+
+   [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>.
+
+10.2.  Informative References
+
+   [RFC4657]  Ash, J., Ed. and 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.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>.
+
+   [PCEP-YANG]
+              Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura,
+              "A YANG Data Model for Path Computation Element
+              Communications Protocol (PCEP)", 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", Work in 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", Work in
+              Progress, Internet-Draft, draft-ietf-pce-association-
+              diversity-14, 26 January 2020,
+              <https://tools.ietf.org/html/draft-ietf-pce-association-
+              diversity-14>.
+
+Appendix A.  Example of an Operator-Configured Association Range
+
+   Consider an Association Type T1 (which allows both dynamic and
+   Operator-configured Associations with a default range of <0x1000,
+   0xffff>).  Consider that, because of the needs of the network, the
+   PCE needs to create more dynamic associations and would like to
+   change the Association Range to <0xbffe, 0xffff> instead.  During
+   PCEP session establishment, the PCE would advertise the new range.
+   The PCC could skip advertising, as the default values are used.  If a
+   PCC is creating a dynamic association (with the PCC as the
+   Association Source), it needs to pick a free Association ID for type
+   T1 in the range <0x1, 0x0fff>, whereas if a PCE is creating a dynamic
+   association (with the PCE as the Association Source), it needs to
+   pick a free Association ID from the range <0x1, 0xbffd>.  Similarly,
+   if an Operator-configured Association is manually configured with the
+   PCC as the Association Source, it should be from the range <0x1000,
+   0xffff>, whereas if the PCE is the Association Source, it should be
+   from the range <0xbffe, 0xffff>.  If the Association Source is not a
+   PCEP peer (for example, an NMS), then the default range of <0x1000,
+   0xffff> is considered.
+
+Acknowledgments
+
+   We would like to thank Yuji Kamite and Joshua George for their
+   contributions to this document.  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 Kühlewind, Martin Vigoureux, Barry
+   Leiba, Eric Vyncke, Suresh Krishnan, and Benjamin Kaduk for the IESG
+   comments.
+
+Contributors
+
+   Stephane Litkowski
+   Orange
+
+   Email: stephane.litkowski@orange.com
+
+
+   Xian Zhang
+   Huawei Technologies
+   F3-1-B RnD Center, Huawei Base
+   Bantian, Longgang District
+   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
+   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
+   United States of America
+
+   Email: msiva@cisco.com
+
+
+   Hariharan Ananthakrishnan
+   Netflix
+
+   Email: hari@netflix.com
+
+
+   Dhruv Dhody
+   Huawei
+   Divyashree Techno Park, Whitefield
+   Bangalore 560066
+   KA
+   India
+
+   Email: dhruv.ietf@gmail.com
+
+
+   Yosuke Tanaka
+   NTT Communications Corporation
+   Granpark Tower 3-4-1 Shibaura, Minato-ku, Tokyo
+   108-8118
+   Japan
+
+   Email: yosuke.tanaka@ntt.com