<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-association-policy-16" number="9005" ipr="trust200902" obsoletes="" submissionType="IETF" category="std" consensus="true" updates=""
     xml:lang="en"> xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="PCEP Extensions for Policy Association">Path Computation Element (PCE) Communication
    Protocol (PCEP) extension Extension for associating Associating Policies and Label Switched
    Paths (LSPs)</title>
    <seriesInfo name="RFC" value="9005"/>
    <author fullname="Stephane Litkowski" initials="S" initials="S." surname="Litkowski">
      <organization>Cisco Systems, Inc.</organization>
      <address>
        <postal>
          <street>11 Rue Camille Desmoulins</street>
          <city>Issy-les-Moulineaux</city>
          <region/>
          <code>92130</code>
          <country>France</country>
        </postal>
        <email>slitkows@cisco.com</email>
      </address>
    </author>
    <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
      <organization>Ciena</organization>
      <address>
        <postal>
          <street>385 Terry Fox Drive</street>
          <city>Kanata</city>
          <region>Ontario</region>
          <code>K2K 0L1</code>
          <country>Canada</country>
        </postal>
        <email>msiva282@gmail.com</email>
      </address>
    </author>
    <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
      <organization>Apstra, Inc.</organization>
      <organization>Juniper Networks</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <email>jefftant.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Jonathan Hardwick" initials="J" surname="Hardwick">
      <organization>Metaswitch Networks</organization>
      <address>
        <postal>
          <street>100 Church Street</street>
          <street>33 Genotin Road</street>
          <city>Enfield</city>

          <region>Middlesex</region>
          <code/>

          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>Jonathan.Hardwick@metaswitch.com</email>
      </address>
    </author>

    <!--<author fullname="Mahendra Singh Negi" initials="M" surname="Negi">
      <organization>RtBrick Inc</organization>

      <address>
        <postal>
          <street>N-17L, 18th Cross Rd, HSR Layout</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560102</code>

          <country>India</country>
        </postal>

        <email>mahend.ietf@gmail.com</email>
      </address>
    </author>-->
    <author fullname="Cheng Li" initials="C." surname="Li">
      <organization>Huawei Technologies</organization> fullname="李呈" asciiFullname="Cheng Li">
      <organization ascii="Huawei Technologies">华为技术有限公司</organization>
      <address>
        <postal>
          <street>Huawei
	 <street ascii="Huawei Campus, No. 156 Beiqing Rd.</street>

          <city>Beijing</city> Rd.">华为北研所</street>
          <city ascii="Beijing">北京</city>
          <region/>
          <code>100095</code>

          <country>China</country>
          <country ascii="China">中国</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>c.l@huawei.com</email>
        <uri/>
      </address>
    </author>
    <date day="21" month="January" month="March" year="2021"/>
    <area>Routing</area>
    <workgroup>PCE Working Group</workgroup>

    <keyword>Association, Policy</keyword>
    <keyword>Association</keyword>
    <keyword>Policy</keyword>
    <abstract>
      <t>This document introduces a simple mechanism to associate policies to with
      a group of Label Switched Paths (LSPs) via an extension to the Path
      Computation Element (PCE) Communication Protocol (PCEP). The extension
      allows a PCEP speaker to advertise to a PCEP peer that a particular LSP
      belongs to a particular Policy Association Group.</t> Group (PAG).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default"> toc="default" numbered="true">
      <name>Introduction</name>
      <t><xref target="RFC5440"/> target="RFC5440" format="default"/> describes the Path Computation Element
      Communication Protocol (PCEP) (PCEP), which enables the communication between a
      Path Computation Client (PCC) and a Path Control Element (PCE), (PCE) or
      between two PCEs based on the PCE architecture <xref target="RFC4655"/>. target="RFC4655" format="default"/>.
      <xref target="RFC5394"/> target="RFC5394" format="default"/> provides additional details on policy within
      the PCE architecture and also provides context for the support of PCE
      Policy.</t>

      <t>PCEP
      policy.</t>
      <t>"Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE Model <xref target="RFC8231"/> PCE" (<xref target="RFC8231" format="default"/>)
      describes a set of extensions to PCEP to enable active control of
      Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
      Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281"/> target="RFC8281" format="default"/> describes the
      set-up
      setup and teardown of PCE-initiated LSPs under the active stateful PCE
      model,
      model without the need for local configuration on the PCC, thus
      allowing for a dynamic network. Currently, the LSPs can either be
      signaled via Resource Reservation Protocol Traffic Engineering (RSVP-TE)
      or can be segment routed as specified in <xref target="RFC8664"/>.</t> target="RFC8664" format="default"/>.</t>
      <t><xref target="RFC8697"/> target="RFC8697" format="default"/> introduces a generic mechanism to create a
      grouping of LSPs which that can then be used to define associations between a
      set of LSPs and a set of attributes (such as configuration parameters or
      behaviors) and is equally applicable to stateful PCE (active and passive
      modes) and stateless PCE.</t>
      <t>This document specifies a PCEP extension to associate one or more
      LSPs with policies using the generic association mechanism.</t>
      <t>A PCEP speaker may want to influence the PCEP peer with respect to
      path selection and other policies. This document describes a PCEP
      extension to associate policies by creating a Policy Association Group
      (PAG) and encoding this association in PCEP messages. The specification
      is applicable to both stateful and stateless PCEP sessions.</t>
      <t>Note that the actual policy definition and the associated parameters
      are out of scope of this document.</t>
      <section title="Requirements Language" toc="default">
        <t>The toc="default" numbered="true">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
        "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP
        14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t>

        <!--
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
        "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
        "OPTIONAL" in this document are to be interpreted as described
        in <xref target="RFC2119"/>.</t>--> here.
        </t>

     </section>
    </section>
    <section title="Terminology" toc="default"> toc="default" numbered="true">
      <name>Terminology</name>
      <t>The following terminology is used in this document.</t>

      <t><list style="hanging">
          <t hangText="Association parameters:">As
      <dl newline="false" spacing="normal">
        <dt>Association parameters:</dt>
        <dd>As described in <xref
          target="RFC8697"/>, target="RFC8697" format="default"/>, 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 Association Source or Extended Association ID -- are included, then they are included in combination with mandatory
          fields to uniquely identify the association group.</t>

          <t hangText="Association information:">As group.</dd>
        <dt>Association information:</dt>
        <dd>As described in <xref
          target="RFC8697"/>, target="RFC8697" format="default"/>, the ASSOCIATION object could include other
          optional TLVs based on the association types, Association Types that provide
          'information'
          "information" related to the association.</t>

          <t hangText="LSR:">Label Switch Router.</t>

          <t hangText="MPLS:">Multiprotocol association.</dd>

        <dt>LSR:</dt>
        <dd>Label Switching Router</dd>
        <dt>MPLS:</dt>
        <dd>Multiprotocol Label Switching.</t>

          <t hangText="PAG:">Policy Association Group.</t>

          <t hangText="PAT:">Policy Association Type.</t>

          <t hangText="PCC:">Path Switching</dd>
        <dt>PAG:</dt>
        <dd>Policy Association Group</dd>
        <dt>PAT:</dt>
        <dd>Policy Association Type</dd>
        <dt>PCC:</dt>
        <dd>Path Computation Client; any client application requesting a
      path computation to be performed by a Path Computation Element.</t>

          <t hangText="PCE:">Path Element.</dd>
        <dt>PCE:</dt>
        <dd>Path Computation Element; an entity (component,
          application, or network node) that is capable of computing a network
          path or route based on a network graph and applying computational
          constraints.</t>

          <t hangText="PCEP:">Path
          constraints.</dd>
        <dt>PCEP:</dt>
        <dd>Path Computation Element Communication
          Protocol.</t>
        </list></t>
          Protocol</dd>
      </dl>
    </section>
    <section title="Motivation" toc="default"> toc="default" numbered="true">
      <name>Motivation</name>
      <t>Paths computed using PCE can be subjected to various policies at both
      the PCE and the PCC. For example, in a centralized traffic engineering
      (TE) TE scenario, network operators may instantiate LSPs and specify
      policies for traffic accounting, path monitoring, telemetry, etc., for
      some LSPs via the Stateful stateful PCE. Similarly, a PCC could request a user-specific
      or service-specific policy to be applied at the PCE, such as a constraints
      relaxation policy policy, to meet optimal QoS and resiliency.</t> resiliency levels.</t>
      <t>PCEP speakers can use the generic mechanism of <xref
      target="RFC8697"/> target="RFC8697" format="default"/> to associate a set of LSPs with a policy, without the need to know the
   details of such a policy.  This simplifies network operations and operations, avoids
   frequent software upgrades, as well as and provides the ability to
   introduce new policies more quickly.</t>
      <t><figure align="left" alt="" anchor="fig1" height=""
          suppress-title="false"
          title="Sample use-cases
      <figure anchor="fig1">
        <name>Sample Use Cases for carrying policies Carrying Policies over PCEP" width=""> PCEP</name>
        <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[ type=""><![CDATA[

                                                         PAG Y
                                          {Service-Specific Policy
                                                    for constraint
            Monitor LSP                                relaxation}
                 |                                          |
                 | PAG X                    PCReq/PCRpt     |
                 V {Monitor LSP}            {PAG Y}         V
              +-----+                   ----------------> +-----+
   _ _ _ _ _ _| PCE |                  |                  | PCE |
  |           +-----+                  |      ----------> +-----+
  | PCInitiate/PCUpd                   |     |    PCReq/PCRpt
  |{PAG X}                             |     |    {PAG Y}
  |                                    |     |
  |              .-----.               |     |         .-----.
  |             (       )              |  +----+      (       )
  |         .--(         )--.          |  |PCC1|--.--(         )--.
  V        (                 )         |  +----+ (                 )
+---+     (                   )        |        (                   )
|PCC|----(   (G)MPLS network    )   +----+     ( (G)MPLS network   )
+---+     (                   )     |PCC2|------(                   )
PAG X      (                 )      +----+       (                 )
{Monitor    '--(         )--'                     '--(         )--'
LSP}            (       )                             (       )
                 '-----'                               '-----'

Case 1: Policy requested by PCE        Case 2: Policy requested by
        and enforced by PCC                    PCC and enforced by
                                               PCE

]]></artwork>
        </figure></t>
      </figure>
      <section title="Policy based Constraints" toc="default"> toc="default" numbered="true">
        <name>Policy-Based Constraints</name>
        <t>In the context of Policy-Enabled Path Computation Framework a policy-enabled path computation framework <xref
        target="RFC5394"/>, target="RFC5394" format="default"/>, path computation policies may be applied at either a PCC or PCC, a PCE PCE, or both.
        A Label Switching Router (LSR) with a policy
        enabled policy-enabled PCC can receive <list style="symbols">
        <t>a receive: </t>
        <ul spacing="normal">
          <li>A service request via signaling, including
        over a Network-Network Interface (NNI) or User-Network Interface (UNI)
        reference point</t>
        <t>a point.</li>
          <li>A configuration request over a management
        interface to establish a service</t>
      </list></t> service.</li>
        </ul>
        <t>The PCC may apply user-specific or
        service-specific policies to decide how the path selection process
        should be constrained, constrained -- that is, which constraints, diversities,
        optimization criterion, criteria, and constraint relaxation constraint-relaxation strategies should be
        applied in order for to increase the likelihood that the service LSP(s) to have a likelihood to will be successfully established and will provide the necessary QoS and resilience
        against network failures. The user-specific or service-specific policies are applied to the PCC and are then passed to the PCE along with the Path path
        computation request, request in the form of constraints <xref
        target="RFC5394"/>.</t>

        <t>PCEP target="RFC5394" format="default"/>.</t>
        <t>The PCEP speaker can use the generic mechanism as per <xref
        target="RFC8697"/> target="RFC8697" format="default"/> to associate a set of LSPs with policies and its
        resulting path computation constraints. user-specific or service-specific policies. This would simplify the path
        computation message exchanges in PCEP.</t>
      </section>
    </section>
    <section title="Overview" toc="default"> toc="default" numbered="true">
      <name>Overview</name>
      <t>As per <xref target="RFC8697"/>, target="RFC8697" format="default"/>, LSPs are associated with other LSPs
      with which they interact by adding them to a common association group.
      Grouping can also be used to define the association between LSPs and the policies associated to with them. As described in <xref target="RFC8697"/>, target="RFC8697" format="default"/>,
      the association group is uniquely identified by the combination of the
      following fields in the ASSOCIATION object: Association Type,
      Association ID, Association Source, and (if present) Global Association
      Source or Extended Association ID. This document defines a new
      Association type, Type called "Policy Association", of Association" with value 3 (early-allocated by IANA), based on the
      generic ASSOCIATION object. This new Association type Type is also called
      "PAT", for
"Policy Association Type".</t> Type" (PAT).</t>
      <t><xref target="RFC8697"/> target="RFC8697" format="default"/> specifies the mechanism for the capability
      advertisement of the Association types Types supported by a PCEP speaker by
      defining a an ASSOC-Type-List TLV to be carried within an OPEN object. This
      capability exchange for the PAT MUST <bcp14>MUST</bcp14> be done before using the
      policy association. Thus
      Policy Association. Thus, the PCEP speaker MUST <bcp14>MUST</bcp14> include the PAT in
      the ASSOC-Type-List TLV and MUST <bcp14>MUST</bcp14> receive the same from the PCEP peer
      before using the Policy Association Group (PAG) PAG in PCEP messages.</t>
      <t>The Policy Association type Type (3) is operator-configured operator configured (as specified in <xref target="RFC8697"/>),
      i.e. target="RFC8697" format="default"/>),
      i.e., the association is created by the operator manually on the PCEP
      peers
      peers, and an LSP belonging to this association is conveyed via PCEP
      messages to the PCEP peer. There is no need to convey an explicit
      Operator-configured Association Range, which could only serve to
      artificially limit the available association Association IDs. Thus, for the Policy Association type, Type, the Operator-configured Association Range MUST
      NOT <bcp14>MUST
      NOT</bcp14> be set, set and MUST <bcp14>MUST</bcp14> be ignored if received.</t>
      <t>A PAG can have one or more LSPs. The association parameters including
      association identifier,
      Association type Identifier, Policy Association Type (PAT), as well as the
      association source
      Association Source IP address are manually configured by the operator and
      are used to identify the PAG as described in <xref target="RFC8697"/>. target="RFC8697" format="default"/>.
      The Global Association Source and Extended Association ID MAY <bcp14>MAY</bcp14> also be
      included.</t>

      <t>As per the processing rules specified in section 6.4 of <xref
      target="RFC8697"/>, target="RFC8697" sectionFormat="of" section="6.4"/>, if a PCEP speaker does not support this Policy
      Association type, Type, it would return a PCErr PCEP error (PCErr) message with Error-Type 26
      "Association Error" and Error-Value Error-value 1 "Association type is not
      supported". The PAG and the policy
      MUST
      <bcp14>MUST</bcp14> be configured on the PCEP peers as per the operator-configured
      association procedures. All further processing is as per section 6.4 of <xref target="RFC8697"/>. target="RFC8697" sectionFormat="of" section="6.4"/>. If a PCE speaker receives a PAG in a PCEP
      message,
      message and the policy association Policy Association information is not configured, it
      MUST
      <bcp14>MUST</bcp14> return a PCErr message with Error-Type 26 "Association Error" and
      Error-Value
      Error-value 4 "Association unknown". <!--If some of the
    association information <xref target='RFC8697'/> (the TLVs defined in this document)
    received from the peer does not match the local configured values, the
    PCEP speaker MUST reject the PCEP message and send a PCErr message with Error-Type 26
   "Association Error" and Error-Value 5 "Operator-configured
   association information mismatch".--></t>
      </t>
      <t>Associating a particular LSP to with multiple policy groups is allowed
      from a protocol perspective, perspective; however, there is no assurance that the
      PCEP speaker will be able to apply multiple policies. If a PCEP speaker
      does not support handling of multiple policies for an LSP, it MUST NOT <bcp14>MUST NOT</bcp14>
      add the LSP into the association group and MUST <bcp14>MUST</bcp14> return a PCErr with
      Error- Type
      Error-Type 26 (Association Error) "Association Error" and Error-value 7 (Cannot "Cannot join the
      association group).</t> group".</t>
    </section>
    <section title="Policy toc="default" numbered="true">
      <name>Policy Association Group" toc="default"> Group</name>
      <t>Association groups and their memberships are defined using the
      ASSOCIATION object defined in <xref target="RFC8697"/>. target="RFC8697" format="default"/>. Two object types
      for IPv4 and IPv6 are defined. The ASSOCIATION object includes
      "Association type" indicating the type of the association group. This
      document add adds a new Association type Type, Policy Association Type (PAT).</t>
      <t>PAG may carry optional TLVs including but not limited to -</t>

      <t><list style="symbols">
          <t>POLICY-PARAMETERS-TLV: Used to:</t>
 <dl newline="true">
        <dt>POLICY-PARAMETERS-TLV:</dt><dd>Used to communicate opaque information useful to apply applying the policy, described in <xref
          target="policy-tlv"/>.</t>

          <t>VENDOR-INFORMATION-TLV: Used target="policy-tlv" format="default"/>.</dd>
        <dt>VENDOR-INFORMATION-TLV:</dt><dd>Used to communicate arbitrary vendor
          specific vendor-specific behavioral information, described in <xref
          target="RFC7470"/>.</t>
        </list></t> target="RFC7470" format="default"/>.</dd>
      </dl>
      <section anchor="policy-tlv" title="Policy Parameters TLV" toc="default">
        <t>The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in toc="default" numbered="true">
        <name>POLICY-PARAMETERS-TLV</name>
<t>
   The ASSOCIATION object (for PAT) to can carry an optional
   POLICY-PARAMETERS-TLV with opaque information that is needed to apply
   the policy at the PCEP peer. In some cases cases, to apply a PCE policy
        successfully, it is required to also associate some policy parameters
        that need to be evaluated. This TLV is used to carry those policy
        parameters. The TLV could include one or more policy related policy-related
        parameters. The encoding format and the order MUST <bcp14>MUST</bcp14> be known to the
        PCEP peers, peers; this could be done during the configuration of the policy
        (and its association parameters) for the PAG. The TLV format is as per
        the format of the PCEP TLVs, as defined in <xref target="RFC5440"/>, target="RFC5440" format="default"/>
        and shown in <xref target="fig-policy-tlv"/>. target="fig-policy-tlv" format="default"/>. Only one
        POLICY-PARAMETERS-TLV can be carried carried, and only the first occurrence is
        processed and any
        processed. Any others MUST <bcp14>MUST</bcp14> be ignored.</t>

        <t><figure align="left" alt="" anchor="fig-policy-tlv" height=""
            suppress-title="false" title="The
        <figure anchor="fig-policy-tlv">
          <name>The POLICY-PARAMETERS-TLV format"
            width=""> Format</name>
          <artwork align="left" alt="" height="" name="" type="" width=""
                     xml:space="preserve"><![CDATA[ type=""><![CDATA[

    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=48               |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                     Policy Parameters                       //
   |                                                               |
   +---------------------------------------------------------------+

]]></artwork>
          </figure></t>
        </figure>

        <t>The type of the POLICY-PARAMETERS-TLV type is 48 (early-allocated by IANA) 48, and it has a variable
        length. The Value field is variable and padded to a 4-byte alignment;
        padding is not included in the Length field. The PCEP peer
        implementation needs to be aware of the encoding format, order, and
        meaning of the 'Policy Parameters' policy parameters well in advance based on the
        policy. Note that from the protocol point of view view, this data is opaque
        and can be used to carry parameters in any format understood by the
        PCEP peers and associated to with the policy. The exact use of this TLV is
        beyond the scope of this document. Examples are included for
        illustration purposes in <xref target="example"/>.</t> target="example" format="default"/>.</t>
        <t>If the PCEP peer is unaware of the policy parameters associated
        with the policy and it receives the POLICY-PARAMETERS-TLV, it MUST <bcp14>MUST</bcp14>
        reject the PCEP message and send a PCErr message with Error-Type 26
        "Association Error" and Error-Value TBD3 Error-value 12 "Not expecting policy
        parameters". Further, if at least one or more parameters parameter in the
        POLICY-PARAMETERS-TLV received by the PCEP speaker are is considered as unacceptable in the context of the associated policy (e.g., out of
        range value, badly encoded value...), value, etc.), the PCEP speaker MUST <bcp14>MUST</bcp14> reject the
        PCEP message and send a PCErr message with Error-Type 26 "Association
        Error" and Error-Value TBD4 Error-value 13 "Unacceptable policy parameters".</t>
        <t>Note that, that the vendor-specific behavioral information is encoded in
        VENDOR-INFORMATION-TLV the VENDOR-INFORMATION-TLV, which can be used along with this TLV.</t>
      </section>
    </section>
    <section anchor="Imp" title="Implementation Status">
      <t>[Note to the RFC Editor - remove this section before publication, as
      well as remove the reference to RFC 7942.]</t>

      <t>This section records the status of known implementations of the
      protocol defined by this specification at the time of posting of this
      Internet-Draft, and is based on a proposal described in <xref
      target="RFC7942"/>. The description of implementations in this section
      is intended to assist the IETF in its decision processes in progressing
      drafts to RFCs. Please note that the listing of any individual
      implementation here does not imply endorsement by the IETF. Furthermore,
      no effort has been spent to verify the information presented here that
      was supplied by IETF contributors. This is not intended as, and must not
      be construed to be, a catalog of available implementations or their
      features. Readers are advised to note that other implementations may
      exist.</t>

      <t>According to <xref target="RFC7942"/>, "this will allow reviewers and
      working groups to assign due consideration to documents that have the
      benefit of running code, which may serve as evidence of valuable
      experimentation and feedback that have made the implemented protocols
      more mature. It is up to the individual working groups to use this
      information as they see fit".</t>

      <section title="Cisco's Implementation" toc="default">
        <t><list style="symbols">
            <t>Organization: Cisco Systems, Inc.</t>

            <t>Implementation: IOS-XR PCE and PCC.</t>

            <t>Description: The PCEP extension specified in this document is
            used to convey traffic steering policies.</t>

            <t>Maturity Level: In shipping product.</t>

            <t>Coverage: Partial.</t>

            <t>Contact: mkoldych@cisco.com</t>
          </list></t>
      </section>
    </section>

    <section title="Security Considerations" toc="default"> toc="default" numbered="true">
      <name>Security Considerations</name>
      <t>The security considerations described in <xref target="RFC8697"/>, target="RFC8697" format="default"/>,
   <xref target="RFC8231"/>, target="RFC8231" format="default"/>, <xref target="RFC5394"/>, target="RFC5394" format="default"/>, and <xref target="RFC5440"/> target="RFC5440" format="default"/> apply to the
   extensions described in this document as well. In particular,
   a malicious PCEP speaker could be spoofed and used as an attack vector
   by creating spurious policy associations Policy Associations as described in <xref target="RFC8697"/>.
   Further target="RFC8697" format="default"/>.
   Further, as described in <xref target="RFC8697"/>, target="RFC8697" format="default"/>, a spurious LSP can have policies that are inconsistent with those of the
   legitimate LSPs of the group and thus and, thus, cause problems in the handling of the policy for the
   legitimate LSPs. It should be noted that policy association Policy Association could provide an adversary with the
   opportunity to eavesdrop on the relationship between the LSPs. <xref target="RFC8697"/> suggest target="RFC8697" format="default"/> suggests that the implementations and operators to use indirect values as a way to hide any sensitive business
   relationships. Thus, securing the PCEP session using Transport Layer Security (TLS)
   <xref target="RFC8253"/>, target="RFC8253" format="default"/>, as per the recommendations and best current practices in
   BCP 195 <xref target="RFC7525"/>, target="RFC7525" format="default"/>, is RECOMMENDED.</t> <bcp14>RECOMMENDED</bcp14>.</t>

      <t>Further, extra care needs to be taken by the implementation with respect to the
      POLICY-PARAMETERS-TLV while decoding, verifying, and applying these
      policy variables. This TLV parsing could be exploited by an
      attacker and thus
      attacker; thus, extra care must be taken while configuring policy association a Policy Association that uses the POLICY-PARAMETERS-TLV and making sure that the data is easy to parse and verify before use. Ensuring agreement among all
relevant PCEP peers as to the format and layout of the policy parameters information is key for the
correct operations. Note that, that the parser for POLICY-PARAMETERS-TLV is particularly
sensitive since it is opque opaque to PCEP and can be used to
convey data with many different internal structure/formats. structures/formats. The choice of decoder is dependent on the additional metadata
associated with the policy and thus incur policy; thus, additional risk of using a wrong decoder and getting garbage results. Use results is incurred. Using standard and well-known policy formats could help
alleviate those risks.
</t>

<t></t>
      <t/>
    </section>
    <section title="IANA Considerations" toc="default"> toc="default" numbered="true">
      <name>IANA Considerations</name>
      <section title="Association object toc="default" numbered="true">
        <name>ASSOCIATION Object Type Indicators" toc="default"> Indicators</name>
        <t>This document defines a new Association type. The sub-registry Type in the subregistry
        "ASSOCIATION Type Field" of the "Path Computation Element Protocol
        (PCEP) Numbers" registry that was originally defined in <xref
        target="RFC8697"/>. IANA is requested to confirm the early-allocated
        codepoint.</t>

        <t><figure align="left" alt="" height="" suppress-title="false"
            title="" width="">
            <artwork align="left" alt="" height="" name="" type="" width=""
                     xml:space="preserve"><![CDATA[
Value     Name                        Reference

3         Policy Association          [This.I-D]
]]></artwork>
          </figure></t>
      </section>

      <section title="PCEP target="RFC8697" format="default"/>.</t>

<table>
  <name/>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>3</td>
      <td>Policy Association</td>
      <td>RFC 9005</td>
    </tr>
  </tbody>
</table>
      </section>
      <section toc="default" numbered="true">
        <name>PCEP TLV Type Indicators" toc="default"> Indicators</name>
        <t>The following TLV Type Indicator value is requested has been registered within the
        "PCEP TLV Type Indicators" subregistry of the "Path Computation
        Element Protocol (PCEP) Numbers" registry. IANA is requested to
        confirm the early-allocated codepoint.</t>

        <t><figure align="left" alt="" height="" suppress-title="false"
            title="" width="">
            <artwork align="left" alt="" height="" name="" type="" width=""
                     xml:space="preserve"><![CDATA[
Value     Description                 Reference

48        POLICY-PARAMETERS-TLV       [This.I-D]
]]></artwork>
          </figure></t>
      </section>

      <section title="PCEP Errors" toc="default"> registry.</t>
<table>
  <name/>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>48</td>
      <td>POLICY-PARAMETERS-TLV</td>
      <td>RFC 9005</td>
    </tr>
  </tbody>
</table>
      </section>
      <section toc="default" numbered="true">
        <name>PCEP Errors</name>
        <t>This document defines new Error-Values Error-values for Error-type Error-Type 26
        "Association Error" defined in <xref target="RFC8697"/>. target="RFC8697" format="default"/>. IANA is
        requested to allocate has allocated new error values within the "PCEP- ERROR "PCEP-ERROR Object
        Error Types and Values" subregistry of the PCEP Numbers "Path Computation Element Protocol (PCEP) Numbers" registry as
        follows:</t>

        <t><figure align="left" alt="" height="" suppress-title="false"
            title="" width="">
            <artwork align="left" alt="" height="" name="" type="" width=""
                     xml:space="preserve"><![CDATA[
Error-Type Meaning     Error-value         Reference

26         Association                     [RFC8697]
           Error
                       TBD3:

<table>
  <name/>
  <thead>
    <tr>
      <th>Error-Type</th>
      <th>Meaning</th>
      <th>Error-value</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>26</td>
      <td>Association Error</td>
      <td></td>
      <td><xref target="RFC8697"/></td>
    </tr>
    <tr>
      <td></td>
      <td></td>
      <td>12: Not expecting [This.I-D] policy parameters

                       TBD4: parameters</td>
      <td>RFC 9005</td>
    </tr>
    <tr>
      <td></td>
      <td></td>
      <td>13: Unacceptable  [This.I-D] policy parameters
]]></artwork>
          </figure></t> parameters</td>
      <td>RFC 9005</td>
    </tr>
  </tbody>
</table>
      </section>
    </section>
    <section title="Manageability Considerations" toc="default">
      <section title="Control toc="default" numbered="true">
      <name>Manageability Considerations</name>
      <section toc="default" numbered="true">
        <name>Control of Function and Policy" toc="default"> Policy</name>

        <t>An operator MUST <bcp14>MUST</bcp14> be allowed to configure the policy associations Policy Associations at
        PCEP peers and associate it them with the LSPs. They MAY <bcp14>MAY</bcp14> also allow
        configuration to related policy parameters, parameters and provide information on
        the encoding format and order to parse the
        associated policy parameters TLV.</t> POLICY-PARAMETERS-TLV.</t>
      </section>
      <section title="Information toc="default" numbered="true">
        <name>Information and Data Models" toc="default"> Models</name>
        <t><xref target="RFC7420"/> target="RFC7420" format="default"/> describes the PCEP MIB; there are no new
        MIB Objects objects for this document.</t>
        <t>The PCEP YANG module is defined in <xref
        target="I-D.ietf-pce-pcep-yang"/>. target="I-D.ietf-pce-pcep-yang" format="default"/>. That module supports associations
        as defined in <xref target="RFC8697"/> and thus target="RFC8697" format="default"/>; thus, it supports the Policy
        Association groups.</t> Groups.</t>

        <t>An implementation SHOULD <bcp14>SHOULD</bcp14> allow the operator to view the PAG
        configured. Further implementation SHOULD <bcp14>SHOULD</bcp14> allow one to view associations
        reported by each peer, peer and the current set of LSPs in the PAG.</t>
      </section>
      <section title="Liveness toc="default" numbered="true">
        <name>Liveness Detection and Monitoring" toc="default">
        <t>Mechanisms Monitoring</name>
        <t>The mechanisms defined in this document do not imply any new liveness
        detection and monitoring requirements in addition to those already
        listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, target="RFC5440" format="default"/> and <xref target="RFC8281"/>.</t> target="RFC8231" format="default"/>.</t>
      </section>
      <section title="Verify toc="default" numbered="true">
        <name>Verifying Correct Operations" toc="default"> Operations</name>
        <t>Verifying the correct operation of a policy can be
   performed by monitoring various parameters as described in <xref target="RFC5440"/> target="RFC5440" format="default"/> and <xref target="RFC8231"/>. target="RFC8231" format="default"/>. A PCEP implementation
   SHOULD
   <bcp14>SHOULD</bcp14> provide information on failed path computation because of appling due to applying policy and log error events, e.g., parsing failure for policy parameters TLV.</t> a POLICY-PARAMETERS-TLV.</t>
      </section>
      <section title="Requirements toc="default" numbered="true">
        <name>Requirements on Other Protocols" toc="default">
        <t>Mechanisms Protocols</name>
        <t>The mechanisms defined in this document do not imply any new
        requirements on other protocols.</t>
      </section>
      <section title="Impact toc="default" numbered="true">
        <name>Impact on Network Operations" toc="default">
        <t>Mechanisms Operations</name>
        <t>The mechanisms defined in this document do not have any impact on
        network operations in addition to those already listed in <xref
        target="RFC5440"/>, target="RFC5440" format="default"/>, <xref target="RFC8231"/>, target="RFC8231" format="default"/>, and <xref
        target="RFC8281"/>.</t> target="RFC8281" format="default"/>.</t>
      </section>
    </section>

    <section title="Acknowledgments" toc="default">
      <t>We would like to acknowledge and thank Santiago Alvarez, Zafar Ali, Luis Tomotaki, Victor Lopez, Rob Shakir, and Clarence Filsfils
  </middle>
  <back>

<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8697.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5394.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7420.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7470.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>

<reference anchor='I-D.ietf-pce-pcep-yang'>
<front>
<title>A YANG Data Model for working on earlier drafts with similar motivation.</t>
      <t>A special thanks to the authors of <xref target="RFC8697"/>, this Path Computation Element Communications Protocol (PCEP)</title>

<author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
    <organization />
</author>

<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
    <organization />
</author>

<author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
    <organization />
</author>

<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
    <organization />
</author>

<date month='February' day='22' year='2021' />

<abstract><t>This document borrowed some of the text from it. The authors would like to
      thank Aijun Wang, Peng Shuping, and Gyan Mishra for their useful
      comments.</t>
      <t>Thanks to Hari for shepherding this document. Thanks to Deborah Brungard defines a YANG data model for providing comments and being the responsible AD for this document.</t>
      <t>Thanks to Nic Leymann management of Path Computation Element communications Protocol (PCEP) for RTGDIR review.</t>
      <t>Thanks to Benjamin Kaduk communications between a Path Computation Client (PCC) and Murray Kucherawy for the comments during IESG review.</t>

    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119.xml" ?>

      <?rfc include="reference.RFC.5440.xml" ?>

      <?rfc include="reference.RFC.8174.xml" ?>

      <?rfc include="reference.RFC.8231.xml" ?>

      <?rfc include="reference.RFC.8253.xml"?>

      <?rfc include="reference.RFC.8697.xml" ?> a Path Computation Element (PCE), or between two PCEs.  The data model includes configuration and state data.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-pce-pcep-yang-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-yang-16.txt' />
</reference>

      </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.4655.xml" ?>

      <?rfc include="reference.RFC.5905.xml" ?>

      <?rfc include="reference.RFC.5394.xml" ?>

      <?rfc include="reference.RFC.7420.xml" ?>

      <?rfc include="reference.RFC.7470.xml" ?>

      <?rfc include="reference.RFC.7525.xml" ?>

      <?rfc include="reference.RFC.7942.xml" ?>

      <?rfc include="reference.RFC.8281.xml"?>

      <?rfc include="reference.RFC.8664.xml"?>

      <?rfc include="reference.I-D.ietf-pce-pcep-yang"?>
    </references>
    <section anchor="example" title="Example toc="default" numbered="true">
      <name>Example of Policy Parameters"
             toc="default"> Parameters</name>
      <t>An example could be a monitoring and telemetry policy P1 policy, P1, that is
      dependent on a profile (GOLD/SILVER/BRONZE) as set by the operator. The
      PCEP peers need to be aware of the policy P1 (and its associated
      characteristics) in advance as well the fact that the policy parameter
      will encode the profile of a type string in the POLICY-PARAMETERS-TLV. As
      an example, LSP1 could encode the PAG with the POLICY-PARAMETERS-TLV
      with a
      using the string "GOLD".</t>

      <t>Another
      <t>The following is another example where the path computation at the PCE could be dependent
      on when the LSP was configured at the PCC. For such a policy policy, P2, the
      time-stamp
      timestamp can be encoded in the POLICY-PARAMETERS-TLV POLICY-PARAMETERS-TLV, and the exact
      encoding could be the 64-bit timestamp format as defined in <xref
      target="RFC5905"/>.</t> target="RFC5905" format="default"/>.</t>
      <t>While the above example has a single field in the
      POLICY-PARAMETERS-TLV, it is possible to include multiple fields, but
      the exact order, encoding format format, and meanings need to be known in
      advance at the PCEP peers.</t>
    </section>
    <section title="Contributor Addresses" toc="default">
      <t><figure align="left" alt="" height="" suppress-title="false" title=""
          width="">
          <artwork align="left" alt="" height="" name="" type="" width=""
                   xml:space="preserve"><![CDATA[
Following toc="default" numbered="false">
      <name>Acknowledgments</name>
      <t>We would like to acknowledge and thank <contact fullname="Santiago Alvarez"/>, <contact fullname="Zafar Ali"/>, <contact fullname="Luis Tomotaki"/>, <contact fullname="Victor Lopez"/>, <contact fullname="Rob Shakir"/>, and <contact fullname="Clarence Filsfils"/> for working on earlier draft versions with similar motivation.</t>
      <t>Special thanks to the authors of <xref target="RFC8697" format="default"/>. This
      document borrowed some of its text. The authors would like to
      thank <contact fullname="Aijun Wang"/>, <contact fullname="Peng Shuping"/>, and <contact fullname="Gyan Mishra"/> for their useful
      comments.</t>
      <t>Thanks to <contact fullname="Hariharan Ananthakrishnan"/> for shepherding this document. Thanks to <contact fullname="Deborah Brungard"/> for providing comments and being the responsible AD for this document.</t>
      <t>Thanks to <contact fullname="Nic Leymann"/> for the RTGDIR review.</t>
      <t>Thanks to <contact fullname="Benjamin Kaduk"/> and <contact fullname="Murray Kucherawy"/> for their comments during the IESG review.</t>
    </section>
    <section toc="default" numbered="false">
      <name>Contributors</name>
<t>
The following individuals have contributed extensively:

Mahendra </t>

   <contact fullname="Mahendra Singh Negi
RtBrick Inc
N-17L, Negi" >
        <organization>RtBrick Inc</organization>
        <address>
          <postal>
            <street>N-17L, 18th Cross Rd, HSR Layout
Bangalore, Karnataka  560102
India

EMail: mahend.ietf@gmail.com

Dhruv Dhody
Huawei Technologies
Divyashree Layout</street>
            <city>Bangalore</city>
            <region>Karnataka</region><code>560102</code>
            <country>India</country>
          </postal>
          <email>mahend.ietf@gmail.com</email>
        </address>
      </contact>

   <contact fullname="Dhruv Dhody">
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>Divyashree Techno Park, Whitefield
Bangalore, Karnataka  560066
India

EMail: dhruv.ietf@gmail.com

Following Whitefield</street>
            <city>Bangalore</city>
            <region>Karnataka</region><code>560066</code>
            <country>India</country>
          </postal>
          <email>dhruv.ietf@gmail.com</email>
        </address>
      </contact>

<t>
The following individuals have contributed text that was incorporated:

Qin Wu
Huawei Technologies
101
</t>
   <contact fullname="Qin Wu">
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>101 Software Avenue, Yuhua District
Nanjing, Jiangsu  210012
China

EMail: sunseawq@huawei.com

Xian Zhang
Huawei Technologies
Bantian, District</street>
            <city>Nanjing</city>
            <region>Jiangsu</region><code>210012</code>
            <country>China</country>
          </postal>
          <email>sunseawq@huawei.com</email>
        </address>
      </contact>

   <contact fullname="Xian Zhang">
        <organization>Huawei Technologies</organization>
        <address>
          <postal>
            <street>Bantian, Longgang District
Shenzhen  518129
P.R.China

EMail: zhang.xian@huawei.com

Udayasree Palle

EMail: udayasreereddy@gmail.com

Mike Koldychev
Cisco District</street>
            <city>Shenzhen</city>
            <region></region><code>518129</code>
            <country>China</country>
          </postal>
          <email>zhang.xian@huawei.com</email>
        </address>
      </contact>

   <contact fullname="Udayasree Palle">
        <organization></organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country></country>
          </postal>
          <email>udayasreereddy@gmail.com</email>
        </address>
      </contact>

   <contact fullname="Mike Koldychev">
        <organization>Cisco Systems, Inc.
Canada

EMail: mkoldych@cisco.com
        ]]></artwork>
        </figure></t> Inc.</organization>
        <address>
          <postal>
            <street></street>
            <city></city>
            <region></region><code></code>
            <country>Canada</country>
          </postal>
          <email>mkoldych@cisco.com</email>
        </address>
      </contact>
    </section>

  </back>
</rfc>