rfc8745xml2.original.xml   rfc8745.xml 
<?xml version="1.0" encoding="windows-1252"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" number="8745" consensus="true" c
<?rfc tocdepth="3"?> ategory="std" docName="draft-ietf-pce-stateful-path-protection-11" ipr="trust200
<?rfc tocindent="yes"?> 902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="tru
<?rfc symrefs="yes"?> e" tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pce-stateful-path-protection-11" ipr="tr
ust200902">
<front> <front>
<title abbrev="Stateful PCE LSP Path Protection">PCEP Extensions for Associa
ting Working and Protection LSPs with Stateful PCE</title> <title abbrev="Stateful PCE LSP Path Protection">Path Computation Element
Communication Protocol (PCEP) Extensions for Associating Working and
Protection Label Switched Paths (LSPs) with Stateful PCE</title>
<seriesInfo name="RFC" value="8745"/>
<author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthak rishnan"> <author fullname="Hariharan Ananthakrishnan" initials="H." surname="Ananthak rishnan">
<organization>Netflix</organization> <organization>Netflix</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>hari@netflix.com</email> <email>hari@netflix.com</email>
</address> </address>
</author> </author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan"> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Cisco</organization> <organization>Cisco</organization>
<address> <address>
<postal> <postal>
<street>2000 Innovation Drive</street> <street>2000 Innovation Drive</street>
<city>Kananta, Ontaria K2K 3E8</city> <city>Kanata</city><region>Ontario</region><code>K2K 3E8</code>
<country>Canada</country> <country>Canada</country>
</postal> </postal>
<email>msiva@cisco.com</email> <email>msiva@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Colby Barth" initials="C." surname="Barth"> <author fullname="Colby Barth" initials="C." surname="Barth">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>1194 N Mathilda Ave,</street> <street>1194 N Mathilda Ave</street>
<city>Sunnyvale, CA, 94086</city> <city>Sunnyvale</city>
<country>USA</country> <region>CA</region><code>94086</code>
</postal> <country>United States of America</country>
<email>cbarth@juniper.net</email> </postal>
</address> <email>cbarth@juniper.net</email>
</address>
</author> </author>
<author fullname="Ina Minei" initials="I." surname="Minei"> <author fullname="Ina Minei" initials="I." surname="Minei">
<organization>Google, Inc</organization> <organization>Google, Inc</organization>
<address> <address>
<postal> <postal>
<street>1600 Amphitheatre Parkway</street> <street>1600 Amphitheatre Parkway</street>
<city>Mountain View, CA, 94043</city> <city>Mountain View</city>
<country>USA</country> <region>CA</region><code>94043</code>
</postal> <country>United States of America</country>
<email>inaminei@google.com</email> </postal>
</address> <email>inaminei@google.com</email>
</address>
</author> </author>
<author initials="M" surname="Negi" fullname="Mahendra Singh Negi"> <author initials="M" surname="Negi" fullname="Mahendra Singh Negi">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560066</code> <code>560066</code>
<country>India</country> <country>India</country>
</postal> </postal>
skipping to change at line 77 skipping to change at line 72
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560066</code> <code>560066</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mahend.ietf@gmail.com</email> <email>mahend.ietf@gmail.com</email>
</address> </address>
</author> </author>
<!-- month and day will be generated automatically by XML2RFC;
be sure the year is current.-->
<date year="2019"/> <!--02 as uploaded--> <date year="2020" month="March"/>
<workgroup>PCE Working Group</workgroup> <workgroup>PCE Working Group</workgroup>
<keyword>PCEP</keyword> <keyword>PCEP</keyword>
<abstract>
<abstract> <t> An active stateful Path Computation Element (PCE) is capable of comput
<t> An active stateful Path Computation Element (PCE) is capable of computing as ing as well as controlling via
well as controlling via
Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switc hing Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). Path Computation Element Communication Protocol (PCEP) Multiprotocol Label Switc hing Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs).
Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or m ore LSPs to provide end-to-end path protection.</t> Furthermore, it is also possible for an active stateful PCE to create, maintain, and delete LSPs. This document defines the PCEP extension to associate two or m ore LSPs to provide end-to-end path protection.</t>
</abstract> </abstract>
</front>
</front> <middle>
<middle>
<section title="Introduction">
<t><xref target="RFC5440"/> describes Path Computation Element Communication Pro
tocol for communication between a Path Computation Client (PCC) and a PCE or
between a pair of PCEs as per <xref target="RFC4655"/>. A PCE computes paths fo
r MPLS-TE Label Switched Paths (LSPs) based on various constraints and optimizat
ion criteria. </t>
<t>Stateful PCE <xref target="RFC8231"/> specifies a set of extensions to PCEP <section numbered="true" toc="default">
to enable <name>Introduction</name>
stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions <t><xref target="RFC5440" format="default"/> describes Path Computation
in compliance with <xref target="RFC4657"/>. Element Communication Protocol (PCEP) for communication between a Path
Computation Client (PCC) and a PCE or between a pair of PCEs as per
<xref target="RFC4655" format="default"/>. A PCE computes paths for
MPLS-TE Label Switched Paths (LSPs) based on various constraints and
optimization criteria. </t>
<t>Stateful PCE <xref target="RFC8231" format="default"/> specifies a set
of extensions to PCEP to enable
stateful control of paths such as MPLS-TE LSPs between and across PCEP sessions
in compliance with <xref target="RFC4657" format="default"/>.
It includes mechanisms to affect LSP state synchronization between PCCs and PCEs , It includes mechanisms to affect LSP state synchronization between PCCs and PCEs ,
delegation of control of LSPs to PCEs, and PCE control of timing and delegation of control of LSPs to PCEs, and PCE control of timing and
sequence of path computations within and across PCEP sessions. The sequence of path computations within and across PCEP sessions. The
focus is on a model where LSPs are configured on the PCC and control focus is on a model where LSPs are configured on the PCC, and control
over them is delegated to the Stateful PCE. over them is delegated to the stateful PCE.
Furthermore, <xref target="RFC8281"/> specifies a mechanism to Furthermore, <xref target="RFC8281" format="default"/> specifies a mechanism to
dynamically instantiate LSPs on a PCC based on the requests from a dynamically instantiate LSPs on a PCC based on the requests from a
stateful PCE or a controller using stateful PCE. stateful PCE or a controller using stateful PCE.
</t> </t>
<t>Path protection <xref target="RFC4427" format="default"/> refers to a p
<t>Path protection <xref target="RFC4427"/> refers to a paradigm in which the wo aradigm in which the working LSP is protected by one or more protection LSP(s).
rking LSP is protected by one or more protection LSP(s).
When the working LSP fails, protection LSP(s) is/are activated. When the working LSPs are computed and controlled When the working LSP fails, protection LSP(s) is/are activated. When the working LSPs are computed and controlled
by the PCE, there is benefit in a mode of operation where protection LSPs are al so computed and controlled by the PCE, there is benefit in a mode of operation where protection LSPs are al so computed and controlled
by the same PCE. <xref target="RFC8051"/> describes applicability of path protec by the same PCE. <xref target="RFC8051" format="default"/> describes the applica
tion in PCE deployments.</t> bility of path protection in PCE deployments.</t>
<t>This document specifies a stateful PCEP extension to associate two or m
<t>This document specifies a stateful PCEP extension to associate two or more LS ore LSPs for the purpose of setting up
Ps for the purpose of setting up
path protection. The extension defined in this document covers the following sce narios: path protection. The extension defined in this document covers the following sce narios:
<list style="symbols"> </t>
<t>A PCC initiates a protection LSP and retains the control of the LSP. The <ul spacing="normal">
PCC computes the path itself or makes a <li>A PCC initiates a protection LSP and retains the control of the LSP.
The PCC computes the path itself or makes a
request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE. request for path computation to a PCE. After the path setup, it reports the information and state of the path to the PCE.
This includes the association group identifying the working and protecti on LSPs. This includes the association group identifying the working and protecti on LSPs.
This is the passive stateful mode <xref target="RFC8051"/>. This is the passive stateful mode <xref target="RFC8051" format="default
</t> "/>.
<t>A PCC initiates a protection LSP and delegates the control of the LSP to </li>
a stateful PCE. During delegation the association group identifying the working <li>A PCC initiates a protection LSP and delegates the control of the
and protection LSPs is included. The PCE LSP to a stateful PCE. During delegation, the association group
computes the path for the protection LSP and updates the PCC with the inform identifying the working and protection LSPs is included. The PCE
ation about the path as long as it controls the LSP. computes the path for the protection LSP and updates the PCC with the
This is the active stateful mode <xref target="RFC8051"/>. information about the path as long as it controls the LSP. This is
</t> the active stateful mode <xref target="RFC8051" format="default"/>.
</li>
<t>A protection LSP could be initiated by a stateful PCE, which retains the <li>A protection LSP could be initiated by a stateful PCE, which retains
control of the LSP. the control of the LSP.
The PCE is responsible for computing the path of the LSP and updating to the PCC with the information about the path. The PCE is responsible for computing the path of the LSP and updating to the PCC with the information about the path.
This is the PCE-Initiated mode <xref target="RFC8281"/>. This is the PCE-Initiated mode <xref target="RFC8281" format="default"/>.
</t> </li>
</ul>
</list> <t>
Note that a protection LSP can be established (signaled) before Note that a protection LSP can be established (signaled) before
the failure (in which case the LSP is said to be in standby mode the failure (in which case the LSP is said to be either in standby mode
<xref target="RFC4427"/> or a Primary LSP <xref target="RFC4872"/>) or after <xref target="RFC4427" format="default"/> or a primary LSP <xref target="RFC4
failure of the 872" format="default"/>) or after failure of the
corresponding working LSP (known as a secondary LSP <xref target="RFC4872"/>) corresponding working LSP (known as a secondary LSP <xref target="RFC4872" fo
. rmat="default"/>).
Whether to establish it before or after failure is according Whether to establish it before or after failure is according
to operator choice or policy. to operator choice or policy.
</t> </t>
<t><xref target="I-D.ietf-pce-association-group"/> introduces a generic mechanis m to <t><xref target="RFC8697" format="default"/> introduces a generic mechanis m to
create a grouping of LSPs, which can then be used to define create a grouping of LSPs, which can then be used to define
associations between a set of LSPs. The mechanism is equally associations between a set of LSPs. The mechanism is equally
applicable to stateful PCE (active and passive modes) and stateless applicable to stateful PCE (active and passive modes) and stateless
PCE.</t> PCE.</t>
<t>This document specifies a PCEP extension to associate one working LSP w
<t>This document specifies a PCEP extension to associate one working LSP with ith one or more
one or more
protection LSPs using the generic association mechanism.</t> protection LSPs using the generic association mechanism.</t>
<t>This document describes a PCEP
<t>This document describes a PCEP extension to associate protection LSPs by creating the Path Protection Associ
extension to associate protection LSPs by creating Path Protection Associatio ation Group (PPAG)
n Group (PPAG)
and encoding this association in PCEP messages for stateful PCEP and encoding this association in PCEP messages for stateful PCEP
sessions. sessions.
</t>
<section title="Requirements Language" toc="default">
<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>
</section>
</section> <!-- Introduction -->
<section title="Terminology">
<t>The following terminologies are used in this document:
<list style="hanging">
<t hangText="ERO:"> Explicit Route Object.</t>
<t hangText="LSP:"> Label Switched Path.</t>
<t hangText="PCC:"> Path Computation Client.</t>
<t hangText="PCE:"> Path Computation Element</t>
<t hangText="PCEP:"> Path Computation Element Communication Protocol.</t
>
<t hangText="PPAG:"> Path Protection Association Group.</t>
<t hangText="TLV:"> Type, Length, and Value.</t>
</list>
</t> </t>
</section> <!-- Terminology -->
<section anchor="Extension-Overview" title="PCEP Extensions">
<section anchor="Path-Protection-Association-Type" title="Path Protection Associ
ation Type">
<t>As per <xref target="I-D.ietf-pce-association-group"/>, LSPs are not associat
ed by listing the other LSPs with which they interact, but rather by making them
belong to an association groups. All LSPs join an association group individually
. The generic ASSOCIATION object is used to associate two
or more LSPs as specified in <xref target="I-D.ietf-pce-association-group"/>. Th
is document defines a new Association type called
"Path Protection Association Type" of value TBD1 and a "Path Protection Associat
ion Group" (PPAG).
A member LSP of a PPAG can
take the role of working or protection LSP. A PPAG can have one working LSP and
/or one or more
protection LSPs. The source, destination, Tunnel ID (as carried in LSP-IDENTIFIE
RS TLV <xref target="RFC8231"/>, with description as per <xref target="RFC3209"/
>), and Protection Type (PT) (in Path Protection Association TLV) of all LSPs wi
thin a PPAG MUST be the same. As per <xref target="RFC3209"/>, TE tunnel is used
to associate a set of LSPs during reroute or to spread a traffic trunk over mul
tiple paths.</t>
<t>The format of the Association object used for PPAG is specified in <section toc="default" numbered="true">
<xref target="I-D.ietf-pce-association-group"/>.</t> <name>Requirements Language</name>
<!--<figure anchor="PPAG-IPv4-Association-Object-Fmt" title="PPAG IPv4 ASSOCIATI <t>
ON Object format"> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
<artwork><![CDATA[ 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>
0 1 2 3 </section>
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 </section>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type = TBD1 | Association |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> <section numbered="true" toc="default">
</figure> <name>Terminology</name>
<t>The following terms are used in this document:
</t>
<ul empty="true">
<li>
<dl newline="false" spacing="normal">
<dt>ERO:</dt>
<dd> Explicit Route Object</dd>
<dt>LSP:</dt>
<dd> Label Switched Path</dd>
<dt>PCC:</dt>
<dd> Path Computation Client</dd>
<dt>PCE:</dt>
<dd> Path Computation Element</dd>
<dt>PCEP:</dt>
<dd> Path Computation Element Communication Protocol</dd>
<dt>PPAG:</dt>
<dd> Path Protection Association Group</dd>
<dt>TLV:</dt>
<dd> Type, Length, and Value</dd>
</dl>
</li>
</ul>
<figure anchor="PPAG-IPv6-Association-Object-Fmt" title="PPAG IPv6 ASSOCIATION O </section>
bject format">
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association type = TBD1 | Association |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> <section anchor="Extension-Overview" numbered="true" toc="default">
</figure> <name>PCEP Extensions</name>
<section anchor="Path-Protection-Association-Type" numbered="true" toc="de
fault">
<name>Path Protection Association Type</name>
<t>As per <xref target="RFC8697"
format="default"/>, LSPs are not associated by listing the other LSPs
with which they interact but, rather, by making them belong to an
association group. All LSPs join an association group
individually. The generic ASSOCIATION object is used to associate two
or more LSPs as specified in <xref
target="RFC8697" format="default"/>. This
document defines a new Association type called "Path Protection
Association Type" of value 1 and a "Path Protection Association
Group" (PPAG). A member LSP of a PPAG can take the role of working or
protection LSP. A PPAG can have one working LSP and/or one or more
protection LSPs. The source, destination, Tunnel ID (as carried in
LSP-IDENTIFIERS TLV <xref target="RFC8231" format="default"/>, with
description as per <xref target="RFC3209" format="default"/>), and
Protection Type (PT) (in Path Protection Association TLV) of all LSPs
within a PPAG <bcp14>MUST</bcp14> be the same. As per <xref
target="RFC3209" format="default"/>, a TE tunnel is used to associate a
set of LSPs during reroute or to spread a traffic trunk over multiple
paths.</t>
<t>The format of the ASSOCIATION object used for PPAG is specified in
<xref target="RFC8697" format="default"/>.</t>
<t><xref target="I-D.ietf-pce-association-group"/> specifies the mechanism fo r the <t><xref target="RFC8697" format="default"/> specifies the mechanism for the
capability advertisement of the Association types supported by a PCEP capability advertisement of the Association types supported by a PCEP
speaker by defining a ASSOC-Type-List TLV to be carried within an speaker by defining an ASSOC-Type-List TLV to be carried within an
OPEN object. This capability exchange for the Association type OPEN object. This capability exchange for the Association type
described in this document (i.e. Path Protection Association Type) MAY be described in this document (i.e., Path Protection Association Type) <bcp14>M
done before using this association, i.e., the PCEP speaker MAY AY</bcp14> be
include the Path Protection Association Type (TBD1) in the ASSOC-Type-List TL done before using this association, i.e., the PCEP speaker <bcp14>MAY</bcp14>
V include the Path Protection Association Type (1) in the ASSOC-Type-List TLV
before using the PPAG in the PCEP messages.</t> before using the PPAG in the PCEP messages.</t>
<t>This Association type is dynamic in nature and created by the PCC or PCE f <t>This Association type is dynamic in nature and created by the PCC
or or PCE for the LSPs belonging to the same TE tunnel (as described in
the LSPs belonging to the same TE tunnel (as described in <xref target="RFC32 <xref target="RFC3209" format="default"/>) originating at the same
09"/>) originating at the same head node and terminating at the same destination head node and terminating at the same destination. These associations
. are conveyed via PCEP messages to the PCEP peer. As per <xref
These associations are conveyed via PCEP messages to the PCEP peer. As per <x target="RFC8697" format="default"/>, the
ref target="I-D.ietf-pce-association-group"/>, association source is set to the local PCEP speaker address that
the association source is set to the local PCEP speaker address that created created the association unless local policy dictates
the association, otherwise. Operator-configured Association Range <bcp14>MUST
unless local policy dictates otherwise. Operator-configured Association Range NOT</bcp14> be set for this Association type and <bcp14>MUST</bcp14>
MUST NOT be set for this Association type and MUST be ignored.</t> be ignored.</t>
</section>
</section> <section anchor="Path-Protection-Association-TLV" numbered="true" toc="def
ault">
<section anchor="Path-Protection-Association-TLV" title="Path Protection Associa <name>Path Protection Association TLV</name>
tion TLV"> <t>The Path Protection Association TLV is an optional TLV for use in
<t>The Path Protection Association TLV is an optional TLV for use in the ASSOCIA the ASSOCIATION object with the Path Protection Association Type. The
TION Object Path Protection Association TLV <bcp14>MUST NOT</bcp14> be present
with the Path Protection Association Type. The Path Protection Association TLV M more than once. If it appears more than once, only the first
UST NOT be present more than once. occurrence is processed and any others <bcp14>MUST</bcp14> be
If it appears more than once, ignored. </t>
only the first occurrence is processed and any others MUST be ignored. </t> <t> The Path Protection Association TLV follows the PCEP TLV format of
<xref target="RFC5440" format="default"/>. </t>
<t> The Path Protection Association TLV follows the PCEP TLV format of <xref tar
get="RFC5440"/>. </t>
<t> The type (16 bits) of the TLV is TBD2. The length <t> The Type (16 bits) of the TLV is 38. The Length
field (16 bit) has a fixed value of 4.</t> field (16 bits) has a fixed value of 4.</t>
<t>The value comprises of a single field, the Path Protection Association <t>The value is comprised of a single field, the Path Protection Associa
tion
Flags (32 bits), where each bit represents a flag option.</t> Flags (32 bits), where each bit represents a flag option.</t>
<!--<t>The value comprises of two fields, the Protection Scheme (PS) (6 bits) an
d the Path Protection Association Flags (26 bits) (where each bit represents a
flag option). </t>-->
<t> The format of the <xref target="PPAG-TLV-Fmt"> Path Protection Association T <t> The format of the Path Protection Association TLV (<xref
LV</xref> is as follows:</t> target="PPAG-TLV-Fmt" format="default"/>) is as
follows:</t>
<figure anchor="PPAG-TLV-Fmt" title="Path Protection Association TLV format"> <figure anchor="PPAG-TLV-Fmt">
<artwork><![CDATA[ <name>Path Protection Association TLV Format</name>
0 1 2 3 <artwork name="" type="" align="left" alt=""><![CDATA[
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
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 = TBD2 | Length = 4 | | Type = 38 | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT | Unassigned Flags |S|P| | PT | Unassigned Flags |S|P|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]
]></artwork>
]]></artwork>
</figure> </figure>
<t>Path Protection Association Flags (32 bits)</t><t>The following flags
are currently defined:
</t>
<ul empty="false" spacing="normal">
<li>Protecting (P): 1 bit - This bit is as defined in <xref
target="RFC4872" sectionFormat="of" section="14.1"/> to indicate if
the LSP is a working (0) or protection (1) LSP.</li>
<li>Secondary (S): 1 bit - This bit is as defined in <xref
target="RFC4872" sectionFormat="of" section="14.1"/> to indicate if
the LSP is a primary (0) or secondary (1) LSP. The S flag is ignored
if the P flag is not set.</li>
<t>Path Protection Association Flags (32 bits) - The following flags are curren <li>Protection Type (PT): 6 bits - This field is as defined in <xref
tly defined - target="RFC4872" sectionFormat="of" section="14.1"/> (as "LSP
<list> (Protection Type) Flags") to indicate the LSP protection type in
<t>Protecting (P): 1 bit - This bit is as defined in Section 14.1 of <xref t use. Any type already defined or that could be defined in the future
arget="RFC4872"/> to indicate if the LSP is a working (0) or protection (1) LSP. for use in the RSVP-TE PROTECTION object is acceptable in this TLV
</t> unless explicitly stated otherwise.</li>
<t>Secondary (S): 1 bit - This bit is as defined in Section 14.1 of <xref ta <li>Unassigned bits are considered reserved. They <bcp14>MUST</bcp14>
rget="RFC4872"/> to indicate if the LSP is a primary (0) or secondary (1) LSP. T be set to 0 on
he S flag is ignored if the P flag is not set.</t> transmission and <bcp14>MUST</bcp14> be ignored on receipt. </li>
<t>Protection Type (PT): 6 bits - This field is as defined in Section 14.1 o </ul>
f <xref target="RFC4872"/> to indicate the LSP protection type in use. Any type
already defined or
that could be defined in the future for use in the RSVP-TE PROTECTION object
is acceptable in this TLV unless explicitly stated otherwise.</t>
<t>Unassigned bits are considered reserved. They MUST be set to 0 on
transmission and MUST be ignored on receipt. </t>
</list></t>
<t>If the TLV is missing in PPAG ASSOCIATION object, it is considered that the L
SP is a working LSP (i.e. as if the P bit is unset).</t>
</section> <!-- PPAG TLV -->
</section> <!-- PCEP extensions -->
<section anchor="Operation" title="Operation"> <t>If the TLV is missing in the PPAG ASSOCIATION object, it is
<t>An LSP is associated with considered that the LSP is a working LSP (i.e., as if the P bit is
other LSPs with which it interacts by adding them to a common unset).</t>
association group via the ASSOCIATION object. All procedures and error-handli </section>
ng for the ASSOCIATION
object is as per <xref target="I-D.ietf-pce-association-group"/>.</t>
<section anchor="Operation-State-Sync" title="State Synchronization"> </section>
<t>During state synchronization, a PCC reports all the existing LSP states as <section anchor="Operation" numbered="true" toc="default">
described in <xref target="RFC8231"/>. <name>Operation</name>
The association group membership pertaining to an LSP is also reported as per <t>An LSP is associated with
<xref target="I-D.ietf-pce-association-group"/>. This other LSPs with which it interacts by adding them to a common
association group via the ASSOCIATION object. All procedures and error handli
ng for the ASSOCIATION
object is as per <xref target="RFC8697" format="default"/>.</t>
<section anchor="Operation-State-Sync" numbered="true" toc="default">
<name>State Synchronization</name>
<t>During state synchronization, a PCC reports all the existing LSP stat
es as described in <xref target="RFC8231" format="default"/>.
The association group membership pertaining to an LSP is also reported as per
<xref target="RFC8697" format="default"/>. This
includes PPAGs.</t> includes PPAGs.</t>
</section>
</section> <!-- State Synchronization --> <section anchor="Operation-PCC-Init" numbered="true" toc="default">
<name>PCC-Initiated LSPs</name>
<section anchor="Operation-PCC-Init" title="PCC-Initiated LSPs"> <t>A PCC can associate a set of LSPs under its control for path
protection purposes. Similarly, the PCC can remove one or more LSPs
<t>A PCC can associate a set of LSPs under its control for path protection pur under its control from the corresponding PPAG. In both cases, the PCC
poses. Similarly, the PCC can reports the change in association to PCE(s) via a Path Computation
remove one or more LSPs under its control from the corresponding PPAG. In both Report (PCRpt) message. A PCC can also delegate the working and
cases, the PCC reports protection LSPs to an active stateful PCE, where the PCE would control
the change in association to PCE(s) via Path Computation Report (PCRpt) messag the LSPs. The stateful PCE could update the paths and attributes of
es. A PCC can also delegate the working and protection the LSPs in the association group via a Path Computation Update (PCUpd)
LSPs to an active stateful PCE, where the PCE would control the LSPs. The stat message. A PCE could also update the association to the PCC via a PCUpd
eful PCE could update the paths and attributes of the LSPs in the association gr message. These procedures are described in <xref
oup target="RFC8697" format="default"/>.
via Path Computation Update (PCUpd) message. A PCE could also update the assoc
iation to the PCC via PCUpd message. These procedures are described in <xref tar
get="I-D.ietf-pce-association-group"/>.
</t> </t>
<t>It is expected that both working and protection LSPs are delegated together ( <t>It is expected that both working and protection LSPs are delegated to
and to the same PCE) to avoid any race conditions. Refer to <xref target="I-D.li gether (and to the same PCE) to avoid any race conditions. Refer to <xref target
tkowski-pce-state-sync"/> for the problem description.</t> ="I-D.litkowski-pce-state-sync" format="default"/> for the problem description.<
/t>
</section> <!-- PCC-Initiated LSPs --> </section>
<section anchor="Operation-PCE-Init" title="PCE-Initiated LSPs">
<t>A PCE can create/update working and protection LSPs independently. <section anchor="Operation-PCE-Init" numbered="true" toc="default">
As specified in <xref target="I-D.ietf-pce-association-group"/>, <name>PCE-Initiated LSPs</name>
<t>A PCE can create/update working and protection LSPs independently.
As specified in <xref target="RFC8697" format="default"/>,
Association Groups can be created by both the PCE and the PCC. Association Groups can be created by both the PCE and the PCC.
Further, a PCE can remove a protection LSP from a PPAG as specified in Furthermore, a PCE can remove a protection LSP from a PPAG as specified in
<xref target="I-D.ietf-pce-association-group"/>. The PCE uses PCUpd <xref target="RFC8697" format="default"/>. The PCE uses PCUpd
or Path Computation Initiate (PCInitiate) messages to communicate the associ ation information to the PCC.</t> or Path Computation Initiate (PCInitiate) messages to communicate the associ ation information to the PCC.</t>
</section>
</section> <!-- PCE-Initiated LSPs --> <section anchor="Session-Termination" numbered="true" toc="default">
<name>Session Termination</name>
<section anchor="Session-Termination" title="Session Termination"> <t>As per <xref target="RFC8697"
format="default"/>, the association information is cleared along with
<t>As per <xref target="I-D.ietf-pce-association-group"/> the association info the LSP state information. When a PCEP session is terminated, after
rmation is cleared along with the LSP state expiry of State Timeout Interval at the PCC, the LSP state associated
information. When a PCEP with that PCEP session is reverted to operator-defined default
session is terminated, after expiry of State Timeout Interval at the PCC, parameters or behaviors as per <xref target="RFC8231"
the LSP state associated with that PCEP session is reverted to format="default"/>. The same procedure is also followed for the
operator-defined default parameters or behaviors as per <xref target="RFC8231 association information. On session termination at the PCE, when the
"/>. The same procedure is LSP state reported by PCC is cleared, the association information is
also followed for the association information. On session also cleared as per <xref target="RFC8697"
termination at the PCE, when the LSP state reported by PCC is format="default"/>. Where there are no LSPs in an association group,
cleared, the association information is also cleared as per <xref target="I-D the association is considered to be deleted.</t>
.ietf-pce-association-group"/>. Where there </section>
are no LSPs in a association group, the association is considered to
be deleted.</t>
</section> <!-- State Synchronization -->
<section anchor="Operation-Error-Handling" title="Error Handling">
<t>As per the processing rules specified in section 6.4 of
<xref target="I-D.ietf-pce-association-group"/>, if a PCEP speaker does not s
upport
this Path Protection Association Type, it would return a PCErr message with
Error-Type 26 "Association Error" and Error-Value 1 "Association type is not
supported".</t>
<t>All LSPs (working or protection) within a PPAG MUST belong to the same TE T
unnel (as described in <xref target="RFC3209"/>) and have the same source and de
stination.
If a PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel ID
(as carried in LSP-IDENTIFIERS TLV <xref target="RFC8231"/>, with description a
s per <xref target="RFC3209"/>) or source or destination of the LSP is different
from
the LSP(s) in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 (A
ssociation Error) <xref target="I-D.ietf-pce-association-group"/>
and Error-Value TBD3 (Tunnel ID or End points mismatch for Path Protection Ass
ociation). In case of Path Protection, LSP-IDENTIFIERS TLV SHOULD be included fo
r all LSPs (including Segment Routing (SR) <xref target="I-D.ietf-pce-segment-ro
uting"/>). If the Protection Type (PT) (in Path Protection Association TLV) is d
ifferent from the LSPs in the PPAG, the PCEP speaker MUST send PCErr with Error-
Type 26 (Association Error) <xref target="I-D.ietf-pce-association-group"/>
and Error-Value 6 (Association information mismatch) as per <xref target="I-D.
ietf-pce-association-group"/>.</t>
<t>When the PCEP peer does not support the protection type set in PPAG, the PC
EP peer MUST send PCErr with Error-Type 26 (Association Error)
<xref target="I-D.ietf-pce-association-group"/> and Error-Value TBD5 (Protecti
on type is not supported).</t>
<t>A given LSP MAY belong to more than one PPAG. If there is a conflict betwee
n any of the two PPAGs, the PCEP peer MUST send PCErr with Error-Type 26 (Associ
ation Error) <xref target="I-D.ietf-pce-association-group"/> and Error-Value 6 (
Association information mismatch) as per <xref target="I-D.ietf-pce-association-
group"/>.</t>
<t>When the protection type is set to 1+1 (i.e., protection type=0x08 or 0x10)
, there MUST be at maximum, only one working LSP and one protection LSP within a
PPAG.
If a PCEP speaker attempts to add another working/protection LSP,
the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) <xref tar
get="I-D.ietf-pce-association-group"/>
and Error-Value TBD4 (Attempt to add another working/protection LSP for Path P
rotection Association).</t>
<t>When the protection type is set to 1:N (i.e., protection type=0x04), there
MUST be at maximum, only one working LSP and number of protection LSPs MUST NOT
be more than N within a PPAG. If a PCEP speaker attempts to add another working/
protection LSP,
the PCEP peer MUST send PCErr with Error-Type 26 (Association Error) <xref tar
get="I-D.ietf-pce-association-group"/>
and Error-Value TBD4 (Attempt to add another working/protection LSP for Path P
rotection Association).</t>
<!--<t>When the protection type is set to 1:N with N>1:
<list>
<t>If there is only one PPAG, there MUST be only one working LSP and number of
protection LSPs MUST NOT be more than N within a PPAG.</t>
<t>If there are multiple PPAGs, in each PPAG there must be only one working LS
P and total number of protection LSPs in all the PPAGs MUST NOT be more than N.<
/t>
<t>If above conditions are not satisfied, the PCEP peer MUST send PCErr with E
rror-Type 26 (Early allocation by IANA) (Association Error)
<xref target='I-D.ietf-pce-association-group'></xref> and Error-Value 6 (Ass
ociation information mismatch).</t>
<t>If PCEP peer does not support 1:N protection, the PCEP peer MUST send PCErr
with Error-Type 26 (Early allocation by IANA) (Association Error)
<xref target='I-D.ietf-pce-association-group'></xref> and Error-Value TBD5 (
Protection type is not supported).</t>
</list>
</t>-->
<t>During the make-before-break (MBB) procedure, two paths will briefly coexis
t. The error handling related to number of LSPs allowed in a PPAG MUST NOT be ap
plied during MBB.</t>
<t>All processing as per <xref target="I-D.ietf-pce-association-group"/> conti
nues to apply.</t>
</section> <!-- Error Handling -->
</section> <!-- Operation --> <section anchor="Operation-Error-Handling" numbered="true" toc="default">
<section title="Other Considerations"> <name>Error Handling</name>
<t>The working and protection LSPs are <t>As per the processing rules specified in <xref
typically resource disjoint (e.g., node, SRLG disjoint). This target="RFC8697" sectionFormat="of"
ensures that a single failure will not affect both the working and section="6.4"/>, if a PCEP speaker does not support this Path
protection LSPs. The disjoint requirement for a group of LSPs is handled via Protection Association Type, it would return a PCErr message with
another Association type called Error-Type 26 "Association Error" and Error-Value 1 "Association type
"Disjointness Association", as described in <xref target="I-D.ietf-pce-a is not supported".</t>
ssociation-diversity"/>.
The diversity requirements for the protection LSP are also handled by in
cluding both ASSOCIATION
objects identifying both the protection association group and the disjoi
nt association group for the group of LSPs. The relationship between the Synchro
nization VECtor (SVEC) object and the Disjointness Association is described in s
ection 5.3 of <xref target="I-D.ietf-pce-association-diversity"/>.</t>
<t><xref target="RFC4872"/> introduces the concept and mechanisms to sup
port the
association of one LSP to another LSP across different RSVP Traffic Engineeri
ng (RSVP-TE) sessions using ASSOCIATION and PROTECTION object.
The information in the Path Protection Association TLV in PCEP as received fr
om the PCE is used
to trigger the signaling of working LSP and protection LSP, with the Path
Protection Association Flags mapped to the corresponding fields in the
PROTECTION Object in RSVP-TE.</t>
</section> <t>All LSPs (working or protection) within a PPAG <bcp14>MUST</bcp14>
<section title="IANA Considerations"> belong to the same TE tunnel (as described in <xref target="RFC3209"
<t>[Note to RFC Editor and IANA: Sections 3.1, 3.2, and 4.5 contain "TBD1" throu format="default"/>) and have the same source and destination. If a
gh PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel
"TBD5" those should be replaced by the values that IANA assigns.]</t> ID (as carried in the LSP-IDENTIFIERS TLV <xref target="RFC8231"
<section title="Association Type"> format="default"/>, with a description as per <xref target="RFC3209"
format="default"/>) or source or destination of the LSP is different
from the LSP(s) in the PPAG, the PCEP speaker <bcp14>MUST</bcp14> send
PCErr with Error-Type 26 (Association Error) <xref
target="RFC8697" format="default"/> and
Error-Value 9 (Tunnel ID or endpoints mismatch for Path Protection
Association). In case of Path Protection, an LSP-IDENTIFIERS TLV
<bcp14>SHOULD</bcp14> be included for all LSPs (including Segment
Routing (SR) <xref target="RFC8664"
format="default"/>). If the Protection Type (PT) (in the Path Protection
Association TLV) is different from the LSPs in the PPAG, the PCEP
speaker <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association
Error) <xref target="RFC8697"
format="default"/> and Error-Value 6 (Association information
mismatch) as per <xref target="RFC8697"
format="default"/>.</t>
<t>When the PCEP peer does not support the protection type set in PPAG,
the PCEP peer <bcp14>MUST</bcp14> send PCErr with Error-Type 26 (Association Err
or)
<xref target="RFC8697" format="default"/> and Error-Value 11 (Protection type
is not supported).</t>
<t>A given LSP <bcp14>MAY</bcp14> belong to more than one PPAG. If there
is a conflict between any of the two PPAGs, the PCEP peer <bcp14>MUST</bcp14> s
end PCErr with Error-Type 26 (Association Error) <xref target="RFC8697" format="
default"/> and Error-Value 6 (Association information mismatch) as per <xref tar
get="RFC8697" format="default"/>.</t>
<t>When the protection type is set to 1+1 (i.e., protection type=0x08
or 0x10), there <bcp14>MUST</bcp14> be at maximum only one working LSP
and one protection LSP within a PPAG. If a PCEP speaker attempts to
add another working/protection LSP, the PCEP peer <bcp14>MUST</bcp14>
send PCErr with Error-Type 26 (Association Error) <xref
target="RFC8697" format="default"/> and Error-Value 10 (Attempt to add
another working/protection LSP for Path Protection Association).</t>
<t>When the protection type is set to 1:N (i.e., protection
type=0x04), there <bcp14>MUST</bcp14> be at maximum only one protection
LSP, and the number of working LSPs <bcp14>MUST NOT</bcp14> be more
than N within a PPAG. If a PCEP speaker attempts to add another
working/protection LSP, the PCEP peer <bcp14>MUST</bcp14> send PCErr
with Error-Type 26 (Association Error) <xref target="RFC8697"
format="default"/> and Error-Value 10 (Attempt to add another
working/protection LSP for Path Protection Association).</t>
<t>This document defines a new Association type, originally <t>During the make-before-break (MBB) procedure, two paths will
defined in <xref target="I-D.ietf-pce-association-group"/>, for path protect briefly coexist. The error handling related to the number of LSPs allowe
ion. d
IANA is requested to make the assignment of a new value for the in a PPAG <bcp14>MUST NOT</bcp14> be applied during MBB.</t>
sub-registry "ASSOCIATION Type Field" (request to be created in <xref target <t>All processing as per <xref target="RFC8697" format="default"/> conti
="I-D.ietf-pce-association-group"/>), as follows: </t> nues to apply.</t>
<texttable> </section>
<ttcol>Association type Value</ttcol><ttcol>Association Name </tt
col><ttcol>Reference</ttcol>
<c> TBD1 </c><c> Path Protection Association</c> <c> This docume
nt </c>
</texttable>
</section> </section>
<section title="Path Protection Association TLV"> <section numbered="true" toc="default">
<name>Other Considerations</name>
<t> This document defines a new TLV for carrying additional information of <t>The working and protection LSPs are typically resource disjoint
LSPs within a path protection association group. (e.g., node, Shared Risk Link Group [SRLG] disjoint). This ensures that
IANA is requested to make the assignment of a new value for the a single failure will not affect both the working and protection
existing "PCEP TLV Type Indicators" registry as follows:</t> LSPs. The disjoint requirement for a group of LSPs is handled via
another Association type called "Disjointness Association" as described
<texttable> in <xref target="I-D.ietf-pce-association-diversity" format="default"/>.
<ttcol>TLV Type Value</ttcol><ttcol>TLV Name</ttcol><ttcol> Reference</t The diversity requirements for the protection LSP are also handled by
tcol> including both ASSOCIATION objects identifying both the protection
<c> TBD2 </c><c>Path Protection Association Group TLV</c> <c> This docum association group and the disjoint association group for the group of
ent </c> LSPs. The relationship between the Synchronization VECtor (SVEC) object
</texttable> and the Disjointness Association is described in <xref
target="I-D.ietf-pce-association-diversity" sectionFormat="of" section="5.
<t> This document requests that a new sub-registry, named "Path protection Assoc 4"/>.</t>
iation Group TLV Flag Field", <t><xref target="RFC4872" format="default"/> introduces the concept and
is created within the "Path Computation mechanisms to support the association of one LSP to another LSP across
Element Protocol (PCEP) Numbers" registry to manage the Flag field in different RSVP Traffic Engineering (RSVP-TE) sessions using the ASSOCIATIO
the Path Protection Association Group TLV. N
New values are to be assigned by Standards Action <xref target="RFC8126"/>. and PROTECTION object. The information in the Path Protection
Each Association TLV in PCEP as received from the PCE is used to trigger the
bit should be tracked with the following qualities: signaling of the working LSP and protection LSP, with the Path Protection
<list style="symbols"> Association Flags mapped to the corresponding fields in the PROTECTION
<t>Bit number (count from 0 as the most significant bit) </t> object in RSVP-TE.</t>
<t>Name flag </t>
<t>Reference </t>
</list>
</t>
<texttable anchor="PPAG-TLV-Table-IANA" title="Path Protection Association TLV F
lag Field">
<ttcol align="center">Bit Number</ttcol>
<ttcol align="center">Name</ttcol>
<ttcol align="center">Reference</ttcol>
<c>31</c>
<c>P - PROTECTION-LSP</c>
<c>This document </c>
<c>30</c>
<c>S - SECONDARY-LSP</c>
<c>This document</c>
<c>6-29</c>
<c>Unassigned</c>
<c>This document</c>
<c>0-5</c>
<c>Protection Type Flags</c>
<c>This document </c>
</texttable>
</section> </section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<section title="PCEP Errors"> <section numbered="true" toc="default">
<name>Association Type</name>
<t>This document defines new Error-Values related to path protection associ <t>This document defines a new Association type, originally
ation for Error-type 26 "Association Error" defined in <xref target="I-D.ietf-pc defined in <xref target="RFC8697" format="default"/>, for path protection.
e-association-group"/>. IANA has assigned new value in the
IANA is requested to allocate new error values within the "PCEP-ERROR "ASSOCIATION Type Field" subregistry (created by <xref target="RFC8697" form
Object Error Types and Values" sub-registry of the PCEP Numbers at="default"/>) as follows: </t>
registry, as follows:</t>
<!--<t>Error-type: 26 "Association Error" <xref target="I-D.ietf-pce-a
ssociation-group"/></t> -->
<texttable>
<ttcol> Error-type </ttcol><ttcol> Error-value </ttcol><ttcol> Meanin
g </ttcol><ttcol> Reference </ttcol>
<c> 26 </c> <c></c><c>Association Error</c><c><xref target="I-D.ietf-
pce-association-group"/></c>
<c></c><c></c><c></c><c></c>
<c></c><c> TBD3 </c> <c>Tunnel ID or End points mismatch for Path Pro
tection Association</c> <c> This document</c>
<c></c><c> TBD4 </c> <c>Attempt to add another working/protection LSP <table align="center">
for Path Protection Association</c> <c> This document</c> <name>ASSOCIATION Type Field
</name>
<thead>
<tr>
<th align="left">Type</th>
<th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1</td>
<td align="left">Path Protection Association</td>
<td align="left">RFC 8745</td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>Path Protection Association TLV</name>
<t> This document defines a new TLV for carrying the additional informat
ion of LSPs within a path protection association group.
IANA has assigned a new value in the
"PCEP TLV Type Indicators" subregistry as follows:</t>
<table align="center">
<name>PCEP TLV Type Indicators
</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">38</td>
<td align="left">Path Protection Association Group TLV</td>
<td align="left">RFC 8745</td>
</tr>
</tbody>
</table>
<t> Per this document, a new subregistry named "Path
protection Association Group TLV Flag Field" has been created within the
"Path Computation Element Protocol (PCEP) Numbers" registry to manage
the Flag field in the Path Protection Association Group TLV. New
values are to be assigned by Standards Action <xref target="RFC8126"
format="default"/>. Each bit should be tracked with the following
qualities:
</t>
<ul spacing="normal">
<li>Bit number (count from 0 as the most significant bit)</li>
<li>Name of the flag</li>
<li>Reference</li>
</ul>
<table anchor="PPAG-TLV-Table-IANA" align="center">
<name>Path Protection Association Group TLV Flag Field</name>
<thead>
<tr>
<th align="center">Bit</th>
<th align="center">Name</th>
<th align="center">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="center">31</td>
<td align="center">P - PROTECTION-LSP</td>
<td align="center">RFC 8745 </td>
</tr>
<tr>
<td align="center">30</td>
<td align="center">S - SECONDARY-LSP</td>
<td align="center">RFC 8745</td>
</tr>
<tr>
<td align="center">6-29</td>
<td align="center">Unassigned</td>
<td align="center">RFC 8745</td>
</tr>
<tr>
<td align="center">0-5</td>
<td align="center">Protection Type Flags</td>
<td align="center">RFC 8745 </td>
</tr>
</tbody>
</table>
</section>
<section numbered="true" toc="default">
<name>PCEP Errors</name>
<t>This document defines new Error-Values related to path protection
association for Error-type 26 "Association Error" defined in <xref
target="RFC8697" format="default"/>. IANA has allocated new error value
s within the "PCEP-ERROR Object
Error Types and Values" subregistry of the PCEP Numbers registry as
follows:</t>
<c></c><c> TBD5 </c> <c>Protection type is not supported</c> <c> This <table align="center">
document</c> <name>PCEP-ERROR Object Error Types and Values
</name>
<thead>
<tr>
<th align="left"> Error-Type </th>
<th align="left"> Meaning </th>
<th align="left"> Error-value </th>
<th align="left"> Reference </th>
</tr>
</thead>
<tbody>
<tr>
<td align="left"> 26 </td>
<td align="left">Association Error</td>
<td align="left"/>
<td align="left">
<xref target="RFC8697" format="default"/></td>
</tr>
</texttable> <tr>
<td align="left"/>
<td align="left"/>
<td align="left">9: Tunnel ID or endpoints mismatch for Path Prote
ction Association</td>
<td align="left">RFC 8745</td>
</tr>
<tr>
<td align="left"/>
<td align="left"/>
<td align="left">10: Attempt to add another working/protection LSP
for Path Protection Association</td>
<td align="left">RFC 8745</td>
</tr>
<tr>
<td align="left"/>
<td align="left"/>
<td align="left">11: Protection type is not supported</td>
<td align="left">RFC 8745</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations"> <t>
<t> The security considerations described in <xref target="RFC8231"
The security considerations described in <xref target="RFC8231"/> format="default"/>, <xref target="RFC8281" format="default"/>,
, and <xref target="RFC5440" format="default"/> apply to the
<xref target="RFC8281"/>, and <xref target="RFC5440"/> extensions described in this document as well. Additional
apply to the extensions described in this document as considerations related to associations where a malicious PCEP
well. Additional considerations related to associations where speaker could be spoofed and could be used as an attack vector
a malicious PCEP speaker could be spoofed and could be used as by creating associations are described in <xref
an attack vector by creating associations as described in <xref target="I-D.i target="RFC8697" format="default"/>.
etf-pce-association-group"/>. Adding a spurious protection LSP to the Path Protection
Adding a spurious protection LSP to the Path Protection Association group cou Association group could give a false sense of network
ld give false sense of network reliability, which leads to issues when the worki reliability, which leads to issues when the working LSP is down
ng LSP is down and the protection LSP fails as well. Thus securing the PCEP sess and the protection LSP fails as well. Thus, securing the PCEP
ion using session using Transport Layer Security (TLS) <xref
Transport Layer Security (TLS) <xref target="RFC8253"/>, as per the target="RFC8253" format="default"/>, as per the recommendations
recommendations and best current practices in BCP 195 <xref target="RFC7525"/ and best current practices in BCP 195 <xref target="RFC7525"
>, is format="default"/>, is <bcp14>RECOMMENDED</bcp14>.
RECOMMENDED. </t>
</t>
</section> </section>
<section title="Manageability Considerations" toc="default"> <section toc="default" numbered="true">
<section title="Control of Function and Policy" toc="default"> <name>Manageability Considerations</name>
<section toc="default" numbered="true">
<name>Control of Function and Policy</name>
<t>Mechanisms defined in this document do not imply any control or polic y <t>Mechanisms defined in this document do not imply any control or polic y
requirements in addition to those already listed in requirements in addition to those already listed in
<xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC5440" format="default"/>, <xref target="RFC8231" format
<xref target="RFC8281"/>.</t> ="default"/>, and
<xref target="RFC8281" format="default"/>.</t>
</section> </section>
<section title="Information and Data Models" toc="default"> <section toc="default" numbered="true">
<t><xref target="RFC7420"/> describes the PCEP MIB, there are no new MIB <name>Information and Data Models</name>
Objects <t><xref target="RFC7420" format="default"/> describes the PCEP MIB; the
re are no new MIB Objects
for this document.</t> for this document.</t>
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> supports <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="de fault"/> supports
associations.</t> associations.</t>
</section> </section>
<section title="Liveness Detection and Monitoring" toc="default"> <section toc="default" numbered="true">
<name>Liveness Detection and Monitoring</name>
<t>Mechanisms defined in this document do not imply any new liveness det ection <t>Mechanisms defined in this document do not imply any new liveness det ection
and monitoring requirements in addition to those already listed in and monitoring requirements in addition to those already listed in
<xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC5440" format="default"/>, <xref target="RFC8231" format
<xref target="RFC8281"/>.</t> ="default"/>, and
<xref target="RFC8281" format="default"/>.</t>
</section> </section>
<section title="Verify Correct Operations" toc="default"> <section toc="default" numbered="true">
<name>Verify Correct Operations</name>
<t>Mechanisms defined in this document do not imply any new operation <t>Mechanisms defined in this document do not imply any new operation
verification requirements in addition to those already listed in verification requirements in addition to those already listed in
<xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC5440" format="default"/>, <xref target="RFC8231" format
<xref target="RFC8281"/>.</t> ="default"/>, and
<xref target="RFC8281" format="default"/>.</t>
</section> </section>
<section title="Requirements On Other Protocols" toc="default"> <section toc="default" numbered="true">
<name>Requirements on Other Protocols</name>
<t>Mechanisms defined in this document do not imply any new requirements <t>Mechanisms defined in this document do not imply any new requirements
on other protocols.</t> on other protocols.</t>
</section> </section>
<section title="Impact On Network Operations" toc="default"> <section toc="default" numbered="true">
<name>Impact on Network Operations</name>
<t>Mechanisms defined in this document do not have any impact on <t>Mechanisms defined in this document do not have any impact on
network operations in addition to those already listed in network operations in addition to those already listed in
<xref target="RFC5440"/>, <xref target="RFC8231"/>, and <xref target="RFC5440" format="default"/>, <xref target="RFC8231" format
<xref target="RFC8281"/>.</t> ="default"/>, and
<xref target="RFC8281" format="default"/>.</t>
</section> </section>
</section> </section>
<section title="Acknowledgments">
<t>We would like to thank Jeff Tantsura, Xian Zhang and Greg Mirsky for thei
r contributions to this document.</t>
<t>Thanks to Ines Robles for the RTGDIR review.</t>
<t>Thanks to Pete Resnick for the GENART review.</t>
<t>Thanks to Donald Eastlake for the SECDIR review.</t>
<t>Thanks to Barry Leiba, Benjamin Kaduk, Eric Vyncke, and Roman Danyliw for
the IESG review.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2 <displayreference target="I-D.ietf-pce-pcep-yang" to="PCEP-YANG"/>
119"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3
209"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4
872"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5
440"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7
525"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
126"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
174"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
231"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
253"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8
281"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.
ietf-pce-association-group"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4
427"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4
655"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4
657"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7
420"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8 051"?> <displayreference target="I-D.ietf-pce-association-diversity" to="PCEP-LSP-EXT"/ >
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D. <displayreference target="I-D.litkowski-pce-state-sync" to="STATE-PCE-SYNC"/>
ietf-pce-pcep-yang"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D. <references>
ietf-pce-association-diversity"?> <name>References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D. <references>
ietf-pce-segment-routing"?> <name>Normative References</name>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
litkowski-pce-state-sync"?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3209.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4872.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.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.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.8281.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.4427.xml"/>
<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.4657.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.8051.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.
I-D.ietf-pce-pcep-yang.xml"/>
<!-- draft-ietf-pce-association-diversity-13: I-D exists-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf
-pce-association-diversity.xml"/>
<!-- I-D.ietf-pce-segment-routing: Published as RFC 8664-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.
xml"/>
<!-- draft-litkowski-pce-state-sync-06: I-D expired-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.litk
owski-pce-state-sync.xml"/>
</references>
</references> </references>
<section title="Contributor Addresses" toc="default">
<t>
<figure title="" suppress-title="false" align="left" alt="" width="" height=
"">
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
h="" height=""><![CDATA[
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
EMail: dhruv.ietf@gmail.com <section numbered="false" toc="default">
]]></artwork> <name>Acknowledgments</name>
</figure> <t>We would like to thank <contact fullname="Jeff Tantsura"/>, <contact
</t> fullname="Xian Zhang"/>, and <contact fullname="Greg Mirsky"/> for
their contributions to this document.</t>
<t>Thanks to <contact fullname="Ines Robles"/> for the RTGDIR review.</t>
<t>Thanks to <contact fullname="Pete Resnick"/> for the GENART review.</t>
<t>Thanks to <contact fullname="Donald Eastlake"/> for the SECDIR review.<
/t>
<t>Thanks to <contact fullname="Barry Leiba"/>, <contact
fullname="Benjamin Kaduk"/>, <contact fullname="Éric Vyncke"/>, and <con
tact
fullname="Roman Danyliw"/> for the IESG review.</t>
</section>
<t> <section toc="default" numbered="false">
<figure title="" suppress-title="false" align="left" alt="" width="" height= <name>Contributors</name>
"">
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
h="" height=""><![CDATA[
Raveendra Torvi
Juniper Networks
1194 N Mathilda Ave,
Sunnyvale, CA, 94086
USA
EMail: rtorvi@juniper.net <contact fullname="Dhruv Dhody"
initials="D"
surname="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>
]]></artwork> <contact fullname="Raveendra Torvi" initials="R"
</figure> surname="Torvi">
</t> <organization>Juniper Networks</organization>
<t> <address>
<figure title="" suppress-title="false" align="left" alt="" width="" height= <postal>
""> <street>1194 N Mathilda Ave</street>
<artwork xml:space="preserve" name="" type="" align="left" alt="" widt
h="" height=""><![CDATA[
Edward Crabbe
Individual Contributor
EMail: edward.crabbe@gmail.com <city>Sunnyvale</city>
]]></artwork>
</figure> <region>CA</region>
</t>
</section> <code>94086</code>
</back>
<country>United States of America</country>
</postal>
<email>rtorvi@juniper.net</email>
</address>
</contact>
<contact fullname="Edward Crabbe" initials="E" surname="Crabbe">
<organization>Individual Contributor</organization>
<address>
<postal/>
<email>edward.crabbe@gmail.com</email>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 91 change blocks. 
651 lines changed or deleted 698 lines changed or added

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