rfc9005xml2.original.xml   rfc9005.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-associat
<?rfc tocindent="yes"?> ion-policy-16" number="9005" ipr="trust200902" obsoletes="" submissionType="IETF
<?rfc symrefs="yes" ?> " category="std" consensus="true" updates="" xml:lang="en" tocInclude="true" toc
<?rfc sortrefs="no"?> Depth="4" symRefs="true" sortRefs="true" version="3">
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc compact="yes" ?>
<?rfc iprnotified="Yes" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-ietf-pce-association-policy-16"
ipr="trust200902" obsoletes="" submissionType="IETF" updates=""
xml:lang="en">
<front> <front>
<title abbrev="PCEP Extensions for Policy Association">Path Computation Elem <title abbrev="PCEP Extensions for Policy Association">Path Computation Elem
ent (PCE) Communication ent Communication
Protocol (PCEP) extension for associating Policies and Label Switched Protocol (PCEP) Extension for Associating Policies and Label Switched
Paths (LSPs)</title> Paths (LSPs)</title>
<seriesInfo name="RFC" value="9005"/>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski"> <author fullname="Stephane Litkowski" initials="S." surname="Litkowski">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>11 Rue Camille Desmoulins</street> <street>11 Rue Camille Desmoulins</street>
<city>Issy-les-Moulineaux</city> <city>Issy-les-Moulineaux</city>
<region/> <region/>
<code>92130</code> <code>92130</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>slitkows@cisco.com</email> <email>slitkows@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Ciena</organization> <organization>Ciena</organization>
<address> <address>
<postal> <postal>
<street>385 Terry Fox Drive</street> <street>385 Terry Fox Drive</street>
<city>Kanata</city> <city>Kanata</city>
<region>Ontario</region> <region>Ontario</region>
<code>K2K 0L1</code> <code>K2K 0L1</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>msiva282@gmail.com</email> <email>msiva282@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jeff Tantsura" initials="J" surname="Tantsura"> <author fullname="Jeff Tantsura" initials="J" surname="Tantsura">
<organization>Apstra, Inc.</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country/> <country/>
</postal> </postal>
<email>jefftant.ietf@gmail.com</email> <email>jefftant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jonathan Hardwick" initials="J" surname="Hardwick"> <author fullname="Jonathan Hardwick" initials="J" surname="Hardwick">
<organization>Metaswitch Networks</organization> <organization>Metaswitch Networks</organization>
<address> <address>
<postal> <postal>
<street>100 Church Street</street> <street>33 Genotin Road</street>
<city>Enfield</city> <city>Enfield</city>
<region>Middlesex</region>
<code/> <code/>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>Jonathan.Hardwick@metaswitch.com</email> <email>Jonathan.Hardwick@metaswitch.com</email>
</address> </address>
</author> </author>
<author fullname="李呈" asciiFullname="Cheng Li">
<!--<author fullname="Mahendra Singh Negi" initials="M" surname="Negi"> <organization ascii="Huawei Technologies">华为技术有限公司</organization>
<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>
<address> <address>
<postal> <postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street> <street ascii="Huawei Campus, No. 156 Beiqing Rd.">华为北研所</street>
<city ascii="Beijing">北京</city>
<city>Beijing</city>
<region/> <region/>
<code>100095</code> <code>100095</code>
<country ascii="China">中国</country>
<country>China</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>c.l@huawei.com</email> <email>c.l@huawei.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<date month="March" year="2021"/>
<date day="21" month="January" year="2021"/>
<area>Routing</area> <area>Routing</area>
<workgroup>PCE Working Group</workgroup> <workgroup>PCE Working Group</workgroup>
<keyword>Association</keyword>
<keyword>Association, Policy</keyword> <keyword>Policy</keyword>
<abstract> <abstract>
<t>This document introduces a simple mechanism to associate policies to <t>This document introduces a simple mechanism to associate policies with
a group of Label Switched Paths (LSPs) via an extension to the Path a group of Label Switched Paths (LSPs) via an extension to the Path
Computation Element (PCE) Communication Protocol (PCEP). The extension Computation Element Communication Protocol (PCEP). The extension
allows a PCEP speaker to advertise to a PCEP peer that a particular LSP allows a PCEP speaker to advertise to a PCEP peer that a particular LSP
belongs to a particular Policy Association Group.</t> belongs to a particular Policy Association Group (PAG).</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction" toc="default"> <section toc="default" numbered="true">
<t><xref target="RFC5440"/> describes the Path Computation Element <name>Introduction</name>
Communication Protocol (PCEP) which enables the communication between a <t><xref target="RFC5440" format="default"/> describes the Path Computatio
Path Computation Client (PCC) and a Path Control Element (PCE), or n Element
between two PCEs based on the PCE architecture <xref target="RFC4655"/>. Communication Protocol (PCEP), which enables the communication between a
<xref target="RFC5394"/> provides additional details on policy within Path Computation Client (PCC) and a Path Control Element (PCE) or
between two PCEs based on the PCE architecture <xref target="RFC4655" form
at="default"/>.
<xref target="RFC5394" format="default"/> provides additional details on p
olicy within
the PCE architecture and also provides context for the support of PCE the PCE architecture and also provides context for the support of PCE
Policy.</t> policy.</t>
<t>"Path Computation Element Communication Protocol (PCEP) Extensions for
<t>PCEP Extensions for Stateful PCE Model <xref target="RFC8231"/> Stateful PCE" (<xref target="RFC8231" format="default"/>)
describes a set of extensions to PCEP to enable active control of describes a set of extensions to PCEP to enable active control of
Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and
Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281"/> describes the Generalized MPLS (GMPLS) tunnels. <xref target="RFC8281" format="default"/
set-up and teardown of PCE-initiated LSPs under the active stateful PCE > describes the
model, without the need for local configuration on the PCC, thus setup and teardown of PCE-initiated LSPs under the active stateful PCE
model without the need for local configuration on the PCC, thus
allowing for a dynamic network. Currently, the LSPs can either be allowing for a dynamic network. Currently, the LSPs can either be
signaled via Resource Reservation Protocol Traffic Engineering (RSVP-TE) signaled via Resource Reservation Protocol Traffic Engineering (RSVP-TE)
or can be segment routed as specified in <xref target="RFC8664"/>.</t> or segment routed as specified in <xref target="RFC8664" format="default"/
>.</t>
<t><xref target="RFC8697"/> introduces a generic mechanism to create a <t><xref target="RFC8697" format="default"/> introduces a generic mechanis
grouping of LSPs which can then be used to define associations between a m to create a
grouping of LSPs that can then be used to define associations between a
set of LSPs and a set of attributes (such as configuration parameters or set of LSPs and a set of attributes (such as configuration parameters or
behaviors) and is equally applicable to stateful PCE (active and passive behaviors) and is equally applicable to stateful PCE (active and passive
modes) and stateless PCE.</t> modes) and stateless PCE.</t>
<t>This document specifies a PCEP extension to associate one or more <t>This document specifies a PCEP extension to associate one or more
LSPs with policies using the generic association mechanism.</t> LSPs with policies using the generic association mechanism.</t>
<t>A PCEP speaker may want to influence the PCEP peer with respect to <t>A PCEP speaker may want to influence the PCEP peer with respect to
path selection and other policies. This document describes a PCEP path selection and other policies. This document describes a PCEP
extension to associate policies by creating Policy Association Group extension to associate policies by creating a Policy Association Group
(PAG) and encoding this association in PCEP messages. The specification (PAG) and encoding this association in PCEP messages. The specification
is applicable to both stateful and stateless PCEP sessions.</t> is applicable to both stateful and stateless PCEP sessions.</t>
<t>Note that the actual policy definition and the associated parameters <t>Note that the actual policy definition and the associated parameters
are out of scope of this document.</t> are out of scope of this document.</t>
<section toc="default" numbered="true">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</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 "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Requirements Language" toc="default"> </section>
<t>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 <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>-->
</section>
</section> </section>
<section toc="default" numbered="true">
<section title="Terminology" toc="default"> <name>Terminology</name>
<t>The following terminology is used in this document.</t> <t>The following terminology is used in this document.</t>
<dl newline="false" spacing="normal">
<dt>Association parameters:</dt>
<dd>As described in <xref target="RFC8697" format="default"/>, the combi
nation 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 or Extended Association ID
-- are included, then they are included in combination with mandatory
fields to uniquely identify the association group.</dd>
<dt>Association information:</dt>
<dd>As described in <xref target="RFC8697" format="default"/>, the ASSOC
IATION object could include other
optional TLVs based on the Association Types that provide
"information" related to the association.</dd>
<t><list style="hanging"> <dt>LSR:</dt>
<t hangText="Association parameters:">As described in <xref <dd>Label Switching Router</dd>
target="RFC8697"/>, the combination of the mandatory fields <dt>MPLS:</dt>
Association type, Association ID and Association Source in the <dd>Multiprotocol Label Switching</dd>
ASSOCIATION object uniquely identify the association group. If the <dt>PAG:</dt>
optional TLVs - Global Association Source or Extended Association ID <dd>Policy Association Group</dd>
are included, then they are included in combination with mandatory <dt>PAT:</dt>
fields to uniquely identify the association group.</t> <dd>Policy Association Type</dd>
<dt>PCC:</dt>
<t hangText="Association information:">As described in <xref <dd>Path Computation Client; any client application requesting a
target="RFC8697"/>, the ASSOCIATION object could include other path computation to be performed by a Path Computation Element.</dd>
optional TLVs based on the association types, that provide <dt>PCE:</dt>
'information' related to the association.</t> <dd>Path Computation Element; an entity (component,
<t hangText="LSR:">Label Switch Router.</t>
<t hangText="MPLS:">Multiprotocol Label Switching.</t>
<t hangText="PAG:">Policy Association Group.</t>
<t hangText="PAT:">Policy Association Type.</t>
<t hangText="PCC:">Path Computation Client; any client application req
uesting a
path computation to be performed by a Path Computation Element.</t>
<t hangText="PCE:">Path Computation Element; an entity (component,
application, or network node) that is capable of computing a network application, or network node) that is capable of computing a network
path or route based on a network graph and applying computational path or route based on a network graph and applying computational
constraints.</t> constraints.</dd>
<dt>PCEP:</dt>
<t hangText="PCEP:">Path Computation Element Communication <dd>Path Computation Element Communication
Protocol.</t> Protocol</dd>
</list></t> </dl>
</section> </section>
<section toc="default" numbered="true">
<section title="Motivation" toc="default"> <name>Motivation</name>
<t>Paths computed using PCE can be subjected to various policies at both <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 the PCE and the PCC. For example, in a centralized TE scenario, network op
(TE) scenario, network operators may instantiate LSPs and specify erators may instantiate LSPs and specify
policies for traffic accounting, path monitoring, telemetry, etc., for policies for traffic accounting, path monitoring, telemetry, etc., for
some LSPs via the Stateful PCE. Similarly, a PCC could request a user-spec some LSPs via the stateful PCE. Similarly, a PCC could request a user-spec
ific ific
or service-specific policy to be applied at the PCE, such as constraints or service-specific policy to be applied at the PCE, such as a constraints
relaxation policy to meet optimal QoS and resiliency.</t> relaxation policy, to meet optimal QoS and resiliency levels.</t>
<t>PCEP speakers can use the generic mechanism of <xref target="RFC8697" f
<t>PCEP speakers can use the generic mechanism of <xref ormat="default"/> to associate a set of LSPs with a policy, without the need to
target="RFC8697"/> to associate a set of LSPs with a policy, without the n know the
eed to know the details of such a policy. This simplifies network operations, avoids
details of such a policy. This simplifies network operations and avoids frequent software upgrades, and provides the ability to
frequent software upgrades, as well as provides the ability to
introduce new policies more quickly.</t> introduce new policies more quickly.</t>
<t><figure align="left" alt="" anchor="fig1" height="" <figure anchor="fig1">
suppress-title="false" <name>Sample Use Cases for Carrying Policies over PCEP</name>
title="Sample use-cases for carrying policies over PCEP" width=""> <artwork align="left" alt="" name="" type=""><![CDATA[
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
PAG Y PAG Y
{Service-Specific Policy {Service-Specific Policy
for constraint for constraint
Monitor LSP relaxation} Monitor LSP relaxation}
| | | |
| PAG X PCReq/PCRpt | | PAG X PCReq/PCRpt |
V {Monitor LSP} {PAG Y} V V {Monitor LSP} {PAG Y} V
+-----+ ----------------> +-----+ +-----+ ----------------> +-----+
_ _ _ _ _ _| PCE | | | PCE | _ _ _ _ _ _| PCE | | | PCE |
skipping to change at line 306 skipping to change at line 219
PAG X ( ) +----+ ( ) PAG X ( ) +----+ ( )
{Monitor '--( )--' '--( )--' {Monitor '--( )--' '--( )--'
LSP} ( ) ( ) LSP} ( ) ( )
'-----' '-----' '-----' '-----'
Case 1: Policy requested by PCE Case 2: Policy requested by Case 1: Policy requested by PCE Case 2: Policy requested by
and enforced by PCC PCC and enforced by and enforced by PCC PCC and enforced by
PCE PCE
]]></artwork> ]]></artwork>
</figure></t> </figure>
<section toc="default" numbered="true">
<section title="Policy based Constraints" toc="default"> <name>Policy-Based Constraints</name>
<t>In the context of Policy-Enabled Path Computation Framework <xref <t>In the context of a policy-enabled path computation framework <xref t
target="RFC5394"/>, path computation policies may be applied at either a arget="RFC5394" format="default"/>, path computation policies may be applied at
PCC or a PCE or both. a PCC, a PCE, or both.
A Label Switching Router (LSR) with a policy A Label Switching Router (LSR) with a policy-enabled PCC can receive: </
enabled PCC can receive <list style="symbols"> t>
<t>a service request via signaling, including <ul spacing="normal">
<li>A service request via signaling, including
over a Network-Network Interface (NNI) or User-Network Interface (UNI) over a Network-Network Interface (NNI) or User-Network Interface (UNI)
reference point</t> reference point.</li>
<t>a configuration request over a management <li>A configuration request over a management
interface to establish a service</t> interface to establish a service.</li>
</list></t> </ul>
<t>The PCC may apply user-specific or <t>The PCC may apply user-specific or
service-specific policies to decide how the path selection process service-specific policies to decide how the path selection process
should be constrained, that is, which constraints, diversities, should be constrained -- that is, which constraints, diversities,
optimization criterion, and constraint relaxation strategies should be optimization criteria, and constraint-relaxation strategies should be
applied in order for the service LSP(s) to have a likelihood to be applied to increase the likelihood that the service LSP(s) will be succe
successfully established and provide necessary QoS and resilience ssfully established and will provide the necessary QoS and resilience
against network failures. The user-specific or service-specific policies against network failures. The user-specific or service-specific policies
applied to PCC and are then passed to the PCE along with the Path are applied to the PCC and are then passed to the PCE along with the path
computation request, in the form of constraints <xref computation request in the form of constraints <xref target="RFC5394" fo
target="RFC5394"/>.</t> rmat="default"/>.</t>
<t>The PCEP speaker can use the generic mechanism as per <xref target="R
<t>PCEP speaker can use the generic mechanism as per <xref FC8697" format="default"/> to associate a set of LSPs with user-specific or serv
target="RFC8697"/> to associate a set of LSPs with policies and its ice-specific policies. This would simplify the path
resulting path computation constraints. This would simplify the path
computation message exchanges in PCEP.</t> computation message exchanges in PCEP.</t>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<section title="Overview" toc="default"> <name>Overview</name>
<t>As per <xref target="RFC8697"/>, LSPs are associated with other LSPs <t>As per <xref target="RFC8697" format="default"/>, LSPs are associated w
ith other LSPs
with which they interact by adding them to a common association group. with which they interact by adding them to a common association group.
Grouping can also be used to define the association between LSPs and Grouping can also be used to define the association between LSPs and the p
policies associated to them. As described in <xref target="RFC8697"/>, olicies associated with them. As described in <xref target="RFC8697" format="def
ault"/>,
the association group is uniquely identified by the combination of the the association group is uniquely identified by the combination of the
following fields in the ASSOCIATION object: Association Type, following fields in the ASSOCIATION object: Association Type,
Association ID, Association Source, and (if present) Global Association Association ID, Association Source, and (if present) Global Association
Source or Extended Association ID. This document defines a new Source or Extended Association ID. This document defines a new
Association type, called "Policy Association", of value 3 (early-allocated Association Type called "Policy Association" with value 3 based on the
by IANA), based on the generic ASSOCIATION object. This new Association Type is called
generic ASSOCIATION object. This new Association type is also called "Policy Association Type" (PAT).</t>
"PAT", for "Policy Association Type".</t> <t><xref target="RFC8697" format="default"/> specifies the mechanism for t
he capability
<t><xref target="RFC8697"/> specifies the mechanism for the capability advertisement of the Association Types supported by a PCEP speaker by
advertisement of the Association types supported by a PCEP speaker by defining an ASSOC-Type-List TLV to be carried within an OPEN object. This
defining a ASSOC-Type-List TLV to be carried within an OPEN object. This capability exchange for the PAT <bcp14>MUST</bcp14> be done before using t
capability exchange for the PAT MUST be done before using the he
policy association. Thus the PCEP speaker MUST include the PAT in Policy Association. Thus, the PCEP speaker <bcp14>MUST</bcp14> include the
the ASSOC-Type-List TLV and MUST receive the same from the PCEP peer PAT in
before using the Policy Association Group (PAG) in PCEP messages.</t> the ASSOC-Type-List TLV and <bcp14>MUST</bcp14> receive the same from the
PCEP peer
<t>The Policy Association type (3) is operator-configured (as specified in before using the PAG in PCEP messages.</t>
<xref target="RFC8697"/>), <t>The Policy Association Type (3) is operator configured (as specified in
i.e. the association is created by the operator manually on the PCEP <xref target="RFC8697" format="default"/>),
peers and an LSP belonging to this association is conveyed via PCEP i.e., the association is created by the operator manually on the PCEP
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 messages to the PCEP peer. There is no need to convey an explicit
Operator-configured Association Range, which could only serve to Operator-configured Association Range, which could only serve to
artificially limit the available association IDs. Thus, for Policy Associa artificially limit the available Association IDs. Thus, for the Policy Ass
tion type, ociation Type, the Operator-configured Association Range <bcp14>MUST
Operator-configured Association Range MUST NOT</bcp14> be set and <bcp14>MUST</bcp14> be ignored if received.</t>
NOT be set, and MUST be ignored if received.</t>
<t>A PAG can have one or more LSPs. The association parameters including <t>A PAG can have one or more LSPs. The association parameters including
association identifier, Association type (PAT), as well as the Association Identifier, Policy Association Type (PAT), as well as the
association source IP address are manually configured by the operator and Association Source IP address are manually configured by the operator and
are used to identify the PAG as described in <xref target="RFC8697"/>. are used to identify the PAG as described in <xref target="RFC8697" format
The Global Association Source and Extended Association ID MAY also be ="default"/>.
The Global Association Source and Extended Association ID <bcp14>MAY</bcp1
4> also be
included.</t> included.</t>
<t>As per the processing rules specified in section 6.4 of <xref <t>As per the processing rules specified in <xref target="RFC8697" section
target="RFC8697"/>, if a PCEP speaker does not support this Policy Format="of" section="6.4"/>, if a PCEP speaker does not support this Policy
Association type, it would return a PCErr message with Error-Type 26 Association Type, it would return a PCEP error (PCErr) message with Error-
"Association Error" and Error-Value 1 "Association type is not Type 26
"Association Error" and Error-value 1 "Association type is not
supported". The PAG and the policy supported". The PAG and the policy
MUST be configured on the PCEP peers as per the operator-configured <bcp14>MUST</bcp14> be configured on the PCEP peers as per the operator-co
association procedures. All further processing is as per section 6.4 of nfigured
<xref target="RFC8697"/>. If a PCE speaker receives PAG in a PCEP association procedures. All further processing is as per <xref target="RFC
message, and the policy association information is not configured, it 8697" sectionFormat="of" section="6.4"/>. If a PCE speaker receives a PAG in a P
MUST return a PCErr message with Error-Type 26 "Association Error" and CEP
Error-Value 4 "Association unknown". <!--If some of the message and the Policy Association information is not configured, it
association information <xref target='RFC8697'/> (the TLVs defined in this d <bcp14>MUST</bcp14> return a PCErr message with Error-Type 26 "Association
ocument) Error" and
received from the peer does not match the local configured values, the Error-value 4 "Association unknown".
PCEP speaker MUST reject the PCEP message and send a PCErr message with Erro </t>
r-Type 26 <t>Associating a particular LSP with multiple policy groups is allowed
"Association Error" and Error-Value 5 "Operator-configured from a protocol perspective; however, there is no assurance that the
association information mismatch".--></t>
<t>Associating a particular LSP to multiple policy groups is allowed
from a protocol perspective, however, there is no assurance that the
PCEP speaker will be able to apply multiple policies. If a PCEP speaker 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 does not support handling of multiple policies for an LSP, it <bcp14>MUST
add the LSP into the association group and MUST return a PCErr with NOT</bcp14>
Error- Type 26 (Association Error) and Error-value 7 (Cannot join the add the LSP into the association group and <bcp14>MUST</bcp14> return a PC
association group).</t> Err with
Error-Type 26 "Association Error" and Error-value 7 "Cannot join the
association group".</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Policy Association Group" toc="default"> <name>Policy Association Group</name>
<t>Association groups and their memberships are defined using the <t>Association groups and their memberships are defined using the
ASSOCIATION object defined in <xref target="RFC8697"/>. Two object types ASSOCIATION object defined in <xref target="RFC8697" format="default"/>. T wo object types
for IPv4 and IPv6 are defined. The ASSOCIATION object includes for IPv4 and IPv6 are defined. The ASSOCIATION object includes
"Association type" indicating the type of the association group. This "Association type" indicating the type of the association group. This
document add a new Association type (PAT).</t> document adds a new Association Type, Policy Association Type (PAT).</t>
<t>PAG may carry optional TLVs including but not limited to:</t>
<t>PAG may carry optional TLVs including but not limited to -</t> <dl newline="true">
<dt>POLICY-PARAMETERS-TLV:</dt><dd>Used to communicate opaque informatio
<t><list style="symbols"> n useful to applying the policy, described in <xref target="policy-tlv" format="
<t>POLICY-PARAMETERS-TLV: Used to communicate opaque information default"/>.</dd>
useful to apply the policy, described in <xref <dt>VENDOR-INFORMATION-TLV:</dt><dd>Used to communicate arbitrary vendor
target="policy-tlv"/>.</t> -specific behavioral information, described in <xref target="RFC7470" format="de
fault"/>.</dd>
<t>VENDOR-INFORMATION-TLV: Used to communicate arbitrary vendor </dl>
specific behavioral information, described in <xref <section anchor="policy-tlv" toc="default" numbered="true">
target="RFC7470"/>.</t> <name>POLICY-PARAMETERS-TLV</name>
</list></t> <t>
The ASSOCIATION object (for PAT) can carry an optional
<section anchor="policy-tlv" title="Policy Parameters TLV" toc="default"> POLICY-PARAMETERS-TLV with opaque information that is needed to apply
<t>The POLICY-PARAMETERS-TLV is an optional TLV that can be carried in the policy at the PCEP peer. In some cases, to apply a PCE policy
ASSOCIATION object (for PAT) to carry opaque information needed to
apply the policy at the PCEP peer. In some cases to apply a PCE policy
successfully, it is required to also associate some policy parameters successfully, it is required to also associate some policy parameters
that need to be evaluated. This TLV is used to carry those policy that need to be evaluated. This TLV is used to carry those policy
parameters. The TLV could include one or more policy related parameters. The TLV could include one or more policy-related
parameters. The encoding format and the order MUST be known to the parameters. The encoding format and the order <bcp14>MUST</bcp14> be kno
PCEP peers, this could be done during the configuration of the policy wn to the
PCEP peers; this could be done during the configuration of the policy
(and its association parameters) for the PAG. The TLV format is as per (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"/>, the format of the PCEP TLVs, as defined in <xref target="RFC5440" format
and shown in <xref target="fig-policy-tlv"/>. Only one ="default"/>
POLICY-PARAMETERS-TLV can be carried and only the first occurrence is and shown in <xref target="fig-policy-tlv" format="default"/>. Only one
processed and any others MUST be ignored.</t> POLICY-PARAMETERS-TLV can be carried, and only the first occurrence is
processed. Any others <bcp14>MUST</bcp14> be ignored.</t>
<t><figure align="left" alt="" anchor="fig-policy-tlv" height="" <figure anchor="fig-policy-tlv">
suppress-title="false" title="The POLICY-PARAMETERS-TLV format" <name>The POLICY-PARAMETERS-TLV Format</name>
width=""> <artwork align="left" alt="" name="" type=""><![CDATA[
<artwork align="left" alt="" height="" name="" type="" width=""
xml:space="preserve"><![CDATA[
0 1 2 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 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 | | Type=48 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Policy Parameters // // Policy Parameters //
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The type of the POLICY-PARAMETERS-TLV is 48 (early-allocated by IANA) and it has a variable <t>The POLICY-PARAMETERS-TLV type is 48, and it has a variable
length. The Value field is variable and padded to a 4-byte alignment; length. The Value field is variable and padded to a 4-byte alignment;
padding is not included in the Length field. The PCEP peer padding is not included in the Length field. The PCEP peer
implementation needs to be aware of the encoding format, order, and implementation needs to be aware of the encoding format, order, and
meaning of the 'Policy Parameters' well in advance based on the meaning of the policy parameters well in advance based on the
policy. Note that from the protocol point of view this data is opaque policy. Note that from the protocol point of view, this data is opaque
and can be used to carry parameters in any format understood by the and can be used to carry parameters in any format understood by the
PCEP peers and associated to the policy. The exact use of this TLV is PCEP peers and associated with the policy. The exact use of this TLV is
beyond the scope of this document. Examples are included for beyond the scope of this document. Examples are included for
illustration purposes in <xref target="example"/>.</t> illustration purposes in <xref target="example" format="default"/>.</t>
<t>If the PCEP peer is unaware of the policy parameters associated <t>If the PCEP peer is unaware of the policy parameters associated
with the policy and it receives the POLICY-PARAMETERS-TLV, it MUST with the policy and it receives the POLICY-PARAMETERS-TLV, it <bcp14>MUS T</bcp14>
reject the PCEP message and send a PCErr message with Error-Type 26 reject the PCEP message and send a PCErr message with Error-Type 26
"Association Error" and Error-Value TBD3 "Not expecting policy "Association Error" and Error-value 12 "Not expecting policy
parameters". Further, if one or more parameters in the parameters". Further, if at least one parameter in the
POLICY-PARAMETERS-TLV received by the PCEP speaker are considered as POLICY-PARAMETERS-TLV received by the PCEP speaker is considered unaccep
unacceptable in the context of the associated policy (e.g., out of table in the context of the associated policy (e.g., out of
range value, badly encoded value...), the PCEP speaker MUST reject the range value, badly encoded value, etc.), the PCEP speaker <bcp14>MUST</b
cp14> reject the
PCEP message and send a PCErr message with Error-Type 26 "Association PCEP message and send a PCErr message with Error-Type 26 "Association
Error" and Error-Value TBD4 "Unacceptable policy parameters".</t> Error" and Error-value 13 "Unacceptable policy parameters".</t>
<t>Note that the vendor-specific behavioral information is encoded in th
<t>Note that, the vendor-specific behavioral information is encoded in e VENDOR-INFORMATION-TLV, which can be used along with this TLV.</t>
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> </section>
<section toc="default" numbered="true">
<section title="Security Considerations" toc="default"> <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC8697"/>, <t>The security considerations described in <xref target="RFC8697" format=
<xref target="RFC8231"/>, <xref target="RFC5394"/>, and <xref target="RFC5440 "default"/>,
"/> apply to the <xref target="RFC8231" format="default"/>, <xref target="RFC5394" format="def
ault"/>, and <xref target="RFC5440" format="default"/> apply to the
extensions described in this document as well. In particular, extensions described in this document as well. In particular,
a malicious PCEP speaker could be spoofed and used as an attack vector a malicious PCEP speaker could be spoofed and used as an attack vector
by creating spurious policy associations as described in <xref target="RFC869 by creating spurious Policy Associations as described in <xref target="RFC869
7"/>. 7" format="default"/>.
Further as described in <xref target="RFC8697"/>, a spurious LSP can have pol Further, as described in <xref target="RFC8697" format="default"/>, a spuriou
icies that are inconsistent with those of the s LSP can have policies that are inconsistent with those of the
legitimate LSPs of the group and thus cause problems in handling of the polic legitimate LSPs of the group and, thus, cause problems in the handling of the
y for the policy for the
legitimate LSPs. It should be noted that policy association could provide an legitimate LSPs. It should be noted that Policy Association could provide an
adversary with the adversary with the
opportunity to eavesdrop on the relationship between the LSPs. <xref target=" opportunity to eavesdrop on the relationship between the LSPs. <xref target="
RFC8697"/> suggest that the implementations and operators to use indirect values RFC8697" format="default"/> suggests that the implementations and operators use
as a way to hide any sensitive business indirect values as a way to hide any sensitive business
relationships. Thus, securing the PCEP session using Transport Layer Security (TLS) relationships. Thus, securing the PCEP session using Transport Layer Security (TLS)
<xref target="RFC8253"/>, as per the recommendations and best current practic <xref target="RFC8253" format="default"/>, as per the recommendations and bes
es in t current practices in
BCP 195 <xref target="RFC7525"/>, is RECOMMENDED.</t> BCP 195 <xref target="RFC7525" format="default"/>, is <bcp14>RECOMMENDED</bcp
14>.</t>
<t>Further, extra care needs to be taken by the implementation with respec t to <t>Further, extra care needs to be taken by the implementation with respec t to the
POLICY-PARAMETERS-TLV while decoding, verifying, and applying these POLICY-PARAMETERS-TLV while decoding, verifying, and applying these
policy variables. This TLV parsing could be exploited by an policy variables. This TLV parsing could be exploited by an
attacker and thus extra care must be taken while configuring policy associ attacker; thus, extra care must be taken while configuring a Policy Associ
ation that uses POLICY-PARAMETERS-TLV and making sure that the data is easy to p ation that uses the POLICY-PARAMETERS-TLV and making sure that the data is easy
arse and verify before use. Ensuring agreement among all to parse and verify before use. Ensuring agreement among all
relevant PCEP peers as to the format and layout of the policy parameters informa relevant PCEP peers as to the format and layout of the policy parameters informa
tion is key for the tion is key for
correct operations. Note that, the parser for POLICY-PARAMETERS-TLV is particula correct operations. Note that the parser for POLICY-PARAMETERS-TLV is particular
rly ly
sensitive since it is opque to PCEP and can be used to sensitive since it is opaque to PCEP and can be used to
convey data with many different internal structure/formats. The choice of decode convey data with many different internal structures/formats. The choice of decod
r is dependent on the additional metadata er is dependent on the additional metadata
associated with the policy and thus incur associated with the policy; thus, additional risk of using a wrong decoder and g
additional risk of using a wrong decoder and getting etting garbage results is incurred. Using standard and well-known policy formats
garbage results. Use standard and well-known policy formats could help could help
alleviate those risks. alleviate those risks.
</t> </t>
<t/>
<t></t>
</section> </section>
<section toc="default" numbered="true">
<section title="IANA Considerations" toc="default"> <name>IANA Considerations</name>
<section title="Association object Type Indicators" toc="default"> <section toc="default" numbered="true">
<t>This document defines a new Association type. The sub-registry <name>ASSOCIATION Object Type Indicators</name>
<t>This document defines a new Association Type in the subregistry
"ASSOCIATION Type Field" of the "Path Computation Element Protocol "ASSOCIATION Type Field" of the "Path Computation Element Protocol
(PCEP) Numbers" registry was originally defined in <xref (PCEP) Numbers" registry that was originally defined in <xref target="RF
target="RFC8697"/>. IANA is requested to confirm the early-allocated C8697" format="default"/>.</t>
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] <table>
]]></artwork> <name/>
</figure></t> <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>
<section toc="default" numbered="true">
<section title="PCEP TLV Type Indicators" toc="default"> <name>PCEP TLV Type Indicators</name>
<t>The following TLV Type Indicator value is requested within the <t>The following TLV Type Indicator value has been registered within the
"PCEP TLV Type Indicators" subregistry of the "Path Computation "PCEP TLV Type Indicators" subregistry of the "Path Computation
Element Protocol (PCEP) Numbers" registry. IANA is requested to Element Protocol (PCEP) Numbers" registry.</t>
confirm the early-allocated codepoint.</t> <table>
<name/>
<t><figure align="left" alt="" height="" suppress-title="false" <thead>
title="" width=""> <tr>
<artwork align="left" alt="" height="" name="" type="" width="" <th>Value</th>
xml:space="preserve"><![CDATA[ <th>Description</th>
Value Description Reference <th>Reference</th>
</tr>
48 POLICY-PARAMETERS-TLV [This.I-D] </thead>
]]></artwork> <tbody>
</figure></t> <tr>
<td>48</td>
<td>POLICY-PARAMETERS-TLV</td>
<td>RFC 9005</td>
</tr>
</tbody>
</table>
</section> </section>
<section toc="default" numbered="true">
<section title="PCEP Errors" toc="default"> <name>PCEP Errors</name>
<t>This document defines new Error-Values for Error-type 26 <t>This document defines new Error-values for Error-Type 26
"Association Error" defined in <xref target="RFC8697"/>. IANA is "Association Error" defined in <xref target="RFC8697" format="default"/>
requested to allocate new error values within the "PCEP- ERROR Object . IANA has allocated new error values within the "PCEP-ERROR Object
Error Types and Values" subregistry of the PCEP Numbers registry as Error Types and Values" subregistry of the "Path Computation Element Pro
tocol (PCEP) Numbers" registry as
follows:</t> follows:</t>
<t><figure align="left" alt="" height="" suppress-title="false" <table>
title="" width=""> <name/>
<artwork align="left" alt="" height="" name="" type="" width="" <thead>
xml:space="preserve"><![CDATA[ <tr>
Error-Type Meaning Error-value Reference <th>Error-Type</th>
<th>Meaning</th>
26 Association [RFC8697] <th>Error-value</th>
Error <th>Reference</th>
TBD3: Not expecting [This.I-D] </tr>
policy parameters </thead>
<tbody>
TBD4: Unacceptable [This.I-D] <tr>
policy parameters <td>26</td>
]]></artwork> <td>Association Error</td>
</figure></t> <td></td>
<td><xref target="RFC8697"/></td>
</tr>
<tr>
<td></td>
<td></td>
<td>12: Not expecting policy parameters</td>
<td>RFC 9005</td>
</tr>
<tr>
<td></td>
<td></td>
<td>13: Unacceptable policy parameters</td>
<td>RFC 9005</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section toc="default" numbered="true">
<name>Manageability Considerations</name>
<section toc="default" numbered="true">
<name>Control of Function and Policy</name>
<section title="Manageability Considerations" toc="default"> <t>An operator <bcp14>MUST</bcp14> be allowed to configure the Policy As
<section title="Control of Function and Policy" toc="default"> sociations at
<t>An operator MUST be allowed to configure the policy associations at PCEP peers and associate them with the LSPs. They <bcp14>MAY</bcp14> als
PCEP peers and associate it with the LSPs. They MAY also allow o allow
configuration to related policy parameters, and provide information on configuration to related policy parameters and provide information on
the encoding format and order to parse the the encoding format and order to parse the
associated policy parameters TLV.</t> associated POLICY-PARAMETERS-TLV.</t>
</section> </section>
<section toc="default" numbered="true">
<name>Information and Data Models</name>
<t><xref target="RFC7420" format="default"/> describes the PCEP MIB; the
re are no new
MIB objects for this document.</t>
<t>The PCEP YANG module is defined in <xref target="I-D.ietf-pce-pcep-ya
ng" format="default"/>. That module supports associations
as defined in <xref target="RFC8697" format="default"/>; thus, it suppor
ts the Policy
Association Groups.</t>
<section title="Information and Data Models" toc="default"> <t>An implementation <bcp14>SHOULD</bcp14> allow the operator to view th
<t><xref target="RFC7420"/> describes the PCEP MIB; there are no new e PAG
MIB Objects for this document.</t> configured. Further implementation <bcp14>SHOULD</bcp14> allow one to vi
ew associations
<t>The PCEP YANG module is defined in <xref reported by each peer and the current set of LSPs in the PAG.</t>
target="I-D.ietf-pce-pcep-yang"/>. That module supports associations
as defined in <xref target="RFC8697"/> and thus supports the Policy
Association groups.</t>
<t>An implementation SHOULD allow the operator to view the PAG
configured. Further implementation SHOULD allow to view associations
reported by each peer, and the current set of LSPs in the PAG.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Liveness Detection and Monitoring" toc="default"> <name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness <t>The mechanisms defined in this document do not imply any new liveness
detection and monitoring requirements in addition to those already detection and monitoring requirements in addition to those already
listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, and listed in <xref target="RFC5440" format="default"/> and <xref target="RF
<xref target="RFC8281"/>.</t> C8231" format="default"/>.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Verify Correct Operations" toc="default"> <name>Verifying Correct Operations</name>
<t>Verifying the correct operation of a policy can be <t>Verifying the correct operation of a policy can be
performed by monitoring various parameters as described in <xref target="RFC5 performed by monitoring various parameters as described in <xref target="RFC5
440"/> and <xref target="RFC8231"/>. A PCEP implementation 440" format="default"/> and <xref target="RFC8231" format="default"/>. A PCEP im
SHOULD provide information on failed path computation because of appling poli plementation
cy and log error events, e.g., parsing failure for policy parameters TLV.</t> <bcp14>SHOULD</bcp14> provide information on failed path computation due to a
pplying policy and log error events, e.g., parsing failure for a POLICY-PARAMETE
RS-TLV.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Requirements on Other Protocols" toc="default"> <name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section toc="default" numbered="true">
<section title="Impact on Network Operations" toc="default"> <name>Impact on Network Operations</name>
<t>Mechanisms defined in this document do not have any impact on <t>The mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in <xref network operations in addition to those already listed in <xref target="
target="RFC5440"/>, <xref target="RFC8231"/>, and <xref RFC5440" format="default"/>, <xref target="RFC8231" format="default"/>, and <xre
target="RFC8281"/>.</t> f target="RFC8281" format="default"/>.</t>
</section> </section>
</section> </section>
<section title="Acknowledgments" toc="default">
<t>We would like to acknowledge and thank Santiago Alvarez, Zafar Ali, Lui
s Tomotaki, Victor Lopez, Rob Shakir, and Clarence Filsfils for working on earli
er drafts with similar motivation.</t>
<t>A special thanks to the authors of <xref target="RFC8697"/>, 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 Brungar
d for providing comments and being the responsible AD for this document.</t>
<t>Thanks to Nic Leymann for RTGDIR review.</t>
<t>Thanks to Benjamin Kaduk and Murray Kucherawy for the comments during I
ESG review.</t>
</section>
</middle> </middle>
<back> <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"?> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<?rfc include="reference.RFC.8697.xml" ?> <references>
</references> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5440.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8231.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8253.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8697.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5905.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5394.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7420.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7470.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8281.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8664.xml"/>
<references title="Informative References"> <reference anchor='I-D.ietf-pce-pcep-yang'>
<?rfc include="reference.RFC.4655.xml" ?> <front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (P
CEP)</title>
<?rfc include="reference.RFC.5905.xml" ?> <author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
<organization />
</author>
<?rfc include="reference.RFC.5394.xml" ?> <author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
<organization />
</author>
<?rfc include="reference.RFC.7420.xml" ?> <author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
<organization />
</author>
<?rfc include="reference.RFC.7470.xml" ?> <author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
<?rfc include="reference.RFC.7525.xml" ?> <date month='February' day='22' year='2021' />
<?rfc include="reference.RFC.7942.xml" ?> <abstract><t>This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between t wo PCEs. The data model includes configuration and state data.</t></abstract>
<?rfc include="reference.RFC.8281.xml"?> </front>
<?rfc include="reference.RFC.8664.xml"?> <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>
<?rfc include="reference.I-D.ietf-pce-pcep-yang"?> </references>
</references> </references>
<section anchor="example" toc="default" numbered="true">
<section anchor="example" title="Example of Policy Parameters" <name>Example of Policy Parameters</name>
toc="default"> <t>An example could be a monitoring and telemetry policy, P1, that is
<t>An example could be a monitoring and telemetry policy P1 that is
dependent on a profile (GOLD/SILVER/BRONZE) as set by the operator. The 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 PCEP peers need to be aware of policy P1 (and its associated
characteristics) in advance as well the fact that the policy parameter characteristics) in advance as well the fact that the policy parameter
will encode the profile of type string in the POLICY-PARAMETERS-TLV. As 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 an example, LSP1 could encode the PAG with the POLICY-PARAMETERS-TLV
with a string "GOLD".</t> using the string "GOLD".</t>
<t>The following is another example where the path computation at the PCE
<t>Another example where the path computation at PCE could be dependent could be dependent
on when the LSP was configured at the PCC. For such a policy P2, the on when the LSP was configured at the PCC. For such a policy, P2, the
time-stamp can be encoded in the POLICY-PARAMETERS-TLV and the exact timestamp can be encoded in the POLICY-PARAMETERS-TLV, and the exact
encoding could be the 64-bit timestamp format as defined in <xref encoding could be the 64-bit timestamp format as defined in <xref target="
target="RFC5905"/>.</t> RFC5905" format="default"/>.</t>
<t>While the above example has a single field in the <t>While the above example has a single field in the
POLICY-PARAMETERS-TLV, it is possible to include multiple fields, but POLICY-PARAMETERS-TLV, it is possible to include multiple fields, but
the exact order, encoding format and meanings need to be known in the exact order, encoding format, and meanings need to be known in
advance at the PCEP peers.</t> advance at the PCEP peers.</t>
</section> </section>
<section toc="default" numbered="false">
<name>Acknowledgments</name>
<t>We would like to acknowledge and thank <contact fullname="Santiago Alva
rez"/>, <contact fullname="Zafar Ali"/>, <contact fullname="Luis Tomotaki"/>, <c
ontact fullname="Victor Lopez"/>, <contact fullname="Rob Shakir"/>, and <contact
fullname="Clarence Filsfils"/> for working on earlier draft versions with simil
ar 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 shepherdi
ng 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="M
urray 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: </t>
<section title="Contributor Addresses" toc="default"> <contact fullname="Mahendra Singh Negi" >
<t><figure align="left" alt="" height="" suppress-title="false" title="" <organization>RtBrick Inc</organization>
width=""> <address>
<artwork align="left" alt="" height="" name="" type="" width="" <postal>
xml:space="preserve"><![CDATA[ <street>N-17L, 18th Cross Rd, HSR Layout</street>
Following have contributed extensively: <city>Bangalore</city>
<region>Karnataka</region><code>560102</code>
Mahendra Singh Negi <country>India</country>
RtBrick Inc </postal>
N-17L, 18th Cross Rd, HSR Layout <email>mahend.ietf@gmail.com</email>
Bangalore, Karnataka 560102 </address>
India </contact>
EMail: mahend.ietf@gmail.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com
Following have contributed text that was incorporated:
Qin Wu
Huawei Technologies
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
EMail: sunseawq@huawei.com
Xian Zhang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R.China
EMail: zhang.xian@huawei.com <contact fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city>
<region>Karnataka</region><code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
Udayasree Palle <t>
The following individuals have contributed text that was incorporated:
</t>
<contact fullname="Qin Wu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region><code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</contact>
EMail: udayasreereddy@gmail.com <contact fullname="Xian Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Bantian, Longgang District</street>
<city>Shenzhen</city>
<region></region><code>518129</code>
<country>China</country>
</postal>
<email>zhang.xian@huawei.com</email>
</address>
</contact>
Mike Koldychev <contact fullname="Udayasree Palle">
Cisco Systems, Inc. <organization></organization>
Canada <address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country></country>
</postal>
<email>udayasreereddy@gmail.com</email>
</address>
</contact>
EMail: mkoldych@cisco.com <contact fullname="Mike Koldychev">
]]></artwork> <organization>Cisco Systems, Inc.</organization>
</figure></t> <address>
<postal>
<street></street>
<city></city>
<region></region><code></code>
<country>Canada</country>
</postal>
<email>mkoldych@cisco.com</email>
</address>
</contact>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 136 change blocks. 
585 lines changed or deleted 583 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/