rfc9059xml2.original.xml   rfc9059.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC3209 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3209.xml">
<!ENTITY RFC5440 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5440.xml">
<!ENTITY RFC7551 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7551.xml">
<!ENTITY RFC8126 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8126.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8231.xml">
<!ENTITY RFC8281 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8281.xml">
<!ENTITY RFC8537 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8537.xml">
<!ENTITY RFC8697 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8697.xml">
<!ENTITY RFC5654 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5654.xml">
<!ENTITY RFC7420 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7420.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7942.xml">
<!ENTITY RFC8051 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8051.xml">
<!ENTITY RFC8253 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8253.xml">
<!ENTITY RFC8408 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8408.xml">
<!ENTITY I-D.ietf-pce-pcep-yang SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibx
ml3/reference.I-D.ietf-pce-pcep-yang.xml">
<!ENTITY I-D.ietf-pce-pcep-stateful-pce-gmpls SYSTEM "https://xml2rfc.ietf.org/p
ublic/rfc/bibxml3/reference.I-D.ietf-pce-pcep-stateful-pce-gmpls.xml">
<!ENTITY I-D.ietf-pce-sr-bidir-path SYSTEM "https://xml2rfc.ietf.org/public/rfc/
bibxml3/reference.I-D.ietf-pce-sr-bidir-path.xml">
]>
<rfc category="std" docName="draft-ietf-pce-association-bidir-14"
ipr="trust200902" submissionType="IETF">
<!-- Generated by id2xml 1.5.0 on 2020-02-01T01:23:15Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="oo*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-associat ion-bidir-14" number="9059" ipr="trust200902" submissionType="IETF" category="st d" consensus="true" obsoletes="" updates="" xml:lang="en" sortRefs="true" symRef s="true" tocInclude="true" version="3">
<?rfc toc="yes"?> <!-- xml2rfc v2v3 conversion 3.5.0 -->
<!-- Generated by id2xml 1.5.0 on 2020-02-01T01:23:15Z -->
<front> <front>
<title abbrev="PCEP for Associated Bidirectional LSP"> Path Computation Elem <title abbrev="PCEP for Associated Bidirectional LSPs">Path Computation Elem
ent Communication Protocol (PCEP) Extensions for Associated Bidirectional Label ent Communication Protocol (PCEP) Extensions for Associated Bidirectional Label
Switched Paths (LSPs)</title> Switched Paths (LSPs)</title>
<seriesInfo name="RFC" value="9059"/>
<author fullname="Rakesh Gandhi" initials="R." role="editor" <author fullname="Rakesh Gandhi" initials="R." role="editor" surname="Gandhi
surname="Gandhi"> ">
<organization>Cisco Systems, Inc.</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Canada</street> <street>Canada</street>
</postal> </postal>
<email>rgandhi@cisco.com</email> <email>rgandhi@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>
<email>cbarth@juniper.net</email> <email>cbarth@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Bin Wen" initials="B." surname="Wen"> <author fullname="Bin Wen" initials="B." surname="Wen">
<organization>Comcast</organization> <organization>Comcast</organization>
<address> <address>
<email>Bin_Wen@cable.comcast.com</email> <email>Bin_Wen@cable.comcast.com</email>
</address> </address>
</author> </author>
<date month="June" year="2021"/>
<date day="21" month="February" year="2021"/>
<workgroup>PCE Working Group</workgroup> <workgroup>PCE Working Group</workgroup>
<abstract> <abstract>
<t/>
<t>This document defines PCEP <t>This document defines Path Computation Element Communication Protocol
extensions for grouping two unidirectional MPLS-TE Label (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched
Switched Paths (LSPs), one in each direction in the network, into an Paths (LSPs), one in each direction in the network, into an associated
Associated Bidirectional LSP. These PCEP extensions bidirectional LSP. These PCEP extensions can be applied either using a
can be applied using a Stateful PCE for both PCE-Initiated stateful PCE for both PCE-initiated and PCC-initiated LSPs or using
and PCC-Initiated LSPs, as well as when using a Stateless PCE. The a stateless PCE. The PCEP procedures defined are applicable
PCEP procedures defined are applicable to the LSPs using RSVP-TE for signa to the LSPs using RSVP-TE for signaling.</t>
ling.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="sect-1" title="Introduction"> <section anchor="sect-1" numbered="true" toc="default">
<t><xref target="RFC5440"/> describes the Path Computation Element <name>Introduction</name>
<t><xref target="RFC5440" format="default"/> describes the Path Computatio
n Element
Communication Protocol (PCEP) as a communication mechanism between a Path Computation Communication Protocol (PCEP) as a communication mechanism between a Path Computation
Client (PCC) and a Path Computation Element (PCE), or between PCE and PCC, Client (PCC) and a Path Computation Element (PCE), or between PCE and PCC,
that enables computation of Multiprotocol Label Switching (MPLS) - Traffic that enables computation of Multiprotocol Label Switching (MPLS) - Traffic
Engineering (TE) Label Switched Paths (LSPs).</t> Engineering (TE) Label Switched Paths (LSPs).</t>
<t><xref target="RFC8231" format="default"/> specifies extensions to PCEP
<t><xref target="RFC8231"/> specifies extensions to PCEP to enable to enable
stateful control of MPLS-TE LSPs. It describes two modes of operation - stateful control of MPLS-TE LSPs. It describes two modes of operation:
Passive Stateful PCE and Active Stateful PCE. In <xref passive stateful PCE and active stateful PCE. In <xref target="RFC8231" fo
target="RFC8231"/>, the focus is on Active Stateful PCE where LSPs are rmat="default"/>, the focus is on active stateful PCE where LSPs are
provisioned on the PCC and control over them is delegated to a PCE. provisioned on the PCC and control over them is delegated to a PCE.
Further, <xref target="RFC8281"/> describes the setup, maintenance and Further, <xref target="RFC8281" format="default"/> describes the setup, ma
teardown of PCE-Initiated LSPs for the Stateful PCE model.</t> intenance, and
teardown of PCE-initiated LSPs for the stateful PCE model.</t>
<t><xref target="RFC8697"/> introduces a generic mechanism to create a gro <t><xref target="RFC8697" format="default"/> introduces a generic mechanis
uping of LSPs. m for creating a grouping of LSPs.
This grouping can then be used to define associations between This grouping can then be used to define associations between
sets of LSPs or between a set of LSPs and a set of attributes, sets of LSPs or between a set of LSPs and a set of attributes,
and it is equally applicable to the stateful PCE (active and and it is equally applicable to the stateful PCE (active and
passive modes) and the stateless PCE.</t> passive modes) and the stateless PCE.</t>
<t>The MPLS Transport Profile (MPLS-TP) requirements document <xref target
<t>The MPLS Transport Profile (MPLS-TP) requirements document <xref ="RFC5654" format="default"/> specifies that
target="RFC5654"/> specifies that "MPLS-TP <bcp14>MUST</bcp14> support unidirectional, co-routed bidirection
"MPLS-TP MUST support unidirectional, co-routed bidirectional, and al, and
associated bidirectional point-to-point transport paths". associated bidirectional point-to-point transport paths".
<xref target="RFC7551"/> defines RSVP <xref target="RFC7551" format="default"/> defines RSVP
signaling extensions for binding forward and reverse unidirectional LSPs signaling extensions for binding forward and reverse unidirectional LSPs
into an associated bidirectional LSP. The fast into an associated bidirectional LSP. The fast
reroute (FRR) procedures for associated bidirectional LSPs are described reroute (FRR) procedures for associated bidirectional LSPs are described
in <xref target="RFC8537"/>.</t> in <xref target="RFC8537" format="default"/>.</t>
<t>This document defines PCEP extensions for grouping two unidirectional <t>This document defines PCEP extensions for grouping two unidirectional
MPLS-TE LSPs into an Associated Bidirectional LSP for both single-sided MPLS-TE LSPs into an associated bidirectional LSP for both single-sided
and double-sided initiation cases when using a Stateful PCE for both and double-sided initiation cases either when using a stateful PCE for bot
PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless h
PCE-initiated and PCC-initiated LSPs or when using a stateless
PCE. The procedures defined are applicable to the LSPs using Resource PCE. The procedures defined are applicable to the LSPs using Resource
Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling <xref t Reservation Protocol - Traffic Engineering (RSVP-TE) for signaling <xref t
arget="RFC3209"/>. arget="RFC3209" format="default"/>.
Specifically, this document defines two new Association Types, "Single-sid Specifically, this document defines two new Association Types, Single-Side
ed d
Bidirectional LSP Association" and "Double-sided Bidirectional Bidirectional LSP Association and Double-Sided Bidirectional
LSP Association", as well as "Bidirectional LSP Association Group TLV" to LSP Association, as well as the Bidirectional LSP Association Group TLV, t
carry o carry
additional information for the association.</t> additional information for the association.</t>
<t>The procedure for associating two unidirectional Segment Routing (SR) p
<t>The procedure for associating two unidirectional Segment Routing (SR) P aths
aths to form an associated bidirectional SR path is defined in
to form an Associated Bidirectional SR Path is defined in <xref target="I-D.ietf-pce-sr-bidir-path" format="default"/> and is outsid
<xref target="I-D.ietf-pce-sr-bidir-path"/>, and is outside the scope of e the scope of
this document.</t> this document.</t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<section anchor="sect-2.1" numbered="true" toc="default">
<name>Key Word Definitions</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 anchor="sect-2" title="Conventions Used in This Document">
<section anchor="sect-2.1" title="Key Word Definitions">
<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>
<section anchor="sect-2.2" numbered="true" toc="default">
<section anchor="sect-2.2" title="Terminology"> <name>Terminology</name>
<t>The reader is assumed to be familiar with the terminology defined <t>The reader is assumed to be familiar with the terminology defined
in <xref target="RFC5440"/>, <xref target="RFC7551"/>, <xref in <xref target="RFC5440" format="default"/>, <xref target="RFC7551" for
target="RFC8231"/>, and <xref target="RFC8697"/>.</t> mat="default"/>, <xref target="RFC8231" format="default"/>, and <xref target="RF
C8697" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="sect-3" numbered="true" toc="default">
<section anchor="sect-3" title="Overview"> <name>Overview</name>
<t>As shown in Figure 1, forward and reverse unidirectional LSPs can be gr <t>As shown in <xref target="ure-example-of-associated-bidirectional-lsp"
ouped />, forward and reverse unidirectional LSPs can be grouped
to form an associated bidirectional LSP. The node A is ingress node for LS to form an associated bidirectional LSP. Node A is the ingress node for LS
P1 and P1 and
egress node for LSP2, whereas node D is ingress node egress node for LSP2, whereas node D is the ingress node
for LSP2 and egress node for LSP1. There are two methods of for LSP2 and egress node for LSP1. There are two methods of
initiating the bidirectional LSP association, single-sided and initiating the Bidirectional LSP Association, single-sided and
double-sided, as defined in <xref target="RFC7551"/> and described in double-sided, as defined in <xref target="RFC7551" format="default"/> and
described in
the following sections.</t> the following sections.</t>
<figure anchor="ure-example-of-associated-bidirectional-lsp">
<figure anchor="ure-example-of-associated-bidirectional-lsp" <name>Example of Associated Bidirectional LSP</name>
title="Example of Associated Bidirectional LSP"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork> LSP1 --> LSP1 --> LSP1 -->
LSP1 --&gt; LSP1 --&gt; LSP1 --&gt;
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +--+--+ +--+--+ +-----+ +-----+ +--+--+ +--+--+ +-----+
<-- LSP2 | | &lt;-- LSP2 <-- LSP2 | | &lt;-- LSP2
| | | |
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| E +-----------+ F | | E +-----------+ F |
+-----+ +-----+ +-----+ +-----+
&lt;-- LSP2 <-- LSP2
</artwork> ]]></artwork>
</figure> </figure>
<section anchor="sect-3.1" numbered="true" toc="default">
<section anchor="sect-3.1" title="Single-sided Initiation"> <name>Single-Sided Initiation</name>
<t>As specified in <xref target="RFC7551"/>, in the single-sided case, <t>As specified in <xref target="RFC7551" format="default"/>, in the sin
gle-sided case,
the bidirectional tunnel is provisioned only on one endpoint node the bidirectional tunnel is provisioned only on one endpoint node
(PCC) of the tunnel. Both endpoint nodes act as PCCs. (PCC) of the tunnel. Both endpoint nodes act as PCCs.
Both forward and reverse LSPs of this tunnel are Both forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Single-sided Bidirectional initiated with the Association Type set to "Single-Sided Bidirectional
LSP Association" on the originating endpoint node. The forward and LSP Association" on the originating endpoint node. The forward and
reverse LSPs are identified in the "Bidirectional LSP Association Group reverse LSPs are identified in the Bidirectional LSP Association Group
TLV" of their PCEP ASSOCIATION Objects.</t> TLV of their PCEP ASSOCIATION objects.</t>
<t>The originating endpoint node signals the properties for the reverse <t>The originating endpoint node signals the properties for the reverse
LSP in the RSVP REVERSE_LSP Object <xref target="RFC7551"/> of the LSP in the RSVP REVERSE_LSP object <xref target="RFC7551" format="defaul t"/> of the
forward LSP Path message. The remote endpoint node then creates the forward LSP Path message. The remote endpoint node then creates the
corresponding reverse tunnel and reverse LSP, and signals the reverse LS P in response corresponding reverse tunnel and reverse LSP, and it then signals the re verse LSP in response
to the received RSVP-TE Path message. Similarly, the remote endpoint nod e to the received RSVP-TE Path message. Similarly, the remote endpoint nod e
deletes the reverse LSP when it receives the RSVP-TE message to delete t he forward LSP deletes the reverse LSP when it receives the RSVP-TE message to delete t he forward LSP
<xref target="RFC3209"/>.</t> <xref target="RFC3209" format="default"/>.</t>
<t>As specified in <xref target="RFC8537"/>, for fast reroute bypass <t>As specified in <xref target="RFC8537" format="default"/>, for fast r eroute bypass
tunnel assignment, the LSP starting from the originating endpoint node i s tunnel assignment, the LSP starting from the originating endpoint node i s
identified as the forward LSP of the single-sided initiated identified as the forward LSP of the single-sided initiated
bidirectional LSP.</t> bidirectional LSP.</t>
<section anchor="sect-3.1.1" numbered="true" toc="default">
<section anchor="sect-3.1.1" title="PCE-Initiated Single-sided Bidirection <name>PCE-Initiated Single-Sided Bidirectional LSP</name>
al LSP"> <figure anchor="ure-example-of-pce-initiated-single-sided-bidirectiona
l-lsp">
<figure anchor="ure-example-of-pce-initiated-single-sided-bidirectional- <name>Example of PCE-Initiated Single-Sided Bidirectional LSP</name>
lsp" <artwork name="" type="" align="left" alt=""><![CDATA[
title="Example of PCE-Initiated Single-sided Bidirectional LSP">
<artwork>
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: | \
Tunnel 1 (F) | \ Tunnel 1 (F) | \
(LSP1 (F, 0), LSP2 (R, 0)) | \ (LSP1 (F, 0), LSP2 (R, 0)) | \
Association #1 v \ Association #1 v \
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
skipping to change at line 232 skipping to change at line 183
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #1 | \ Association #1 Association #1 | \ Association #1
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, R=Reverse LSP, (0,P1,P2,P3)=PLSP-IDs Legend: F = Forward LSP, R = Reverse LSP, (0,P1,P2,P3) = PLSP-IDs
</artwork> ]]></artwork>
</figure> </figure>
<t>Using partial topology from <xref target="ure-example-of-associated
<t>Using partial topology from Figure 1, as shown in Figure 2, the forwar -bidirectional-lsp"/>, as shown in <xref target="ure-example-of-pce-initiated-si
d tunnel 1 and both forward ngle-sided-bidirectional-lsp"/>, the forward Tunnel 1 and both forward LSP1 and
LSP1 and reverse LSP2 are initiated on the originating endpoint node reverse LSP2 are initiated on the originating endpoint node
A by the PCE. The PLSP-IDs used are P1 and P2 on the originating endpoin A by the PCE. The PCEP-specific LSP identifiers (PLSP-IDs) used are P1 a
t node A nd P2 on the originating endpoint node A
and P3 on the remote endpoint node D. and P3 on the remote endpoint node D.
The originating endpoint node A reports tunnels 1 and forward LSP1 and re The originating endpoint node A reports Tunnel 1 and forward LSP1 and rev
verse LSP2 erse LSP2
to the PCE. The endpoint (PCC) node D reports to the PCE. The endpoint (PCC) node D reports Tunnel 2 and LSP2 to the PC
tunnel 2 and LSP2 to the PCE. E.
</t> </t>
</section>
</section> <section anchor="sect-3.1.2" numbered="true" toc="default">
<name>PCC-Initiated Single-Sided Bidirectional LSP</name>
<section anchor="sect-3.1.2" title="PCC-Initiated Single-sided Bidirection <figure anchor="ure-example-of-pcc-initiated-single-sided-bidirectiona
al LSP"> l-lsp">
<name>Example of PCC-Initiated Single-Sided Bidirectional LSP</name>
<figure anchor="ure-example-of-pcc-initiated-single-sided-bidirectional-ls <artwork name="" type="" align="left" alt=""><![CDATA[
p"
title="Example of PCC-Initiated Single-sided Bidirectional LSP">
<artwork>
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports: Reports/Delegates: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3)) (LSP1 (F, P1), LSP2 (R, P2)) | \ (LSP2 (F, P3))
Association #2 | \ Association #2 Association #2 | \ Association #2
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, R=Reverse LSP, (P1,P2,P3)=PLSP-IDs Legend: F = Forward LSP, R = Reverse LSP, (P1,P2,P3) = PLSP-IDs
</artwork> ]]></artwork>
</figure> </figure>
<t>Using partial topology from <xref target="ure-example-of-associated
<t>Using partial topology from Figure 1, as shown in Figure 3, the forwar -bidirectional-lsp"/>, as shown in <xref target="ure-example-of-pcc-initiated-si
d tunnel 1 and both forward ngle-sided-bidirectional-lsp"/>, the forward Tunnel 1 and both forward LSP1 and
LSP1 and reverse LSP2 are initiated on the originating endpoint node reverse LSP2 are initiated on the originating endpoint node
A (the originating PCC). A (the originating PCC).
The PLSP-IDs used are P1 and P2 on the originating endpoint node A The PLSP-IDs used are P1 and P2 on the originating endpoint node A
and P3 on the remote endpoint node D. and P3 on the remote endpoint node D.
The originating endpoint (PCC) node A may delegate the The originating endpoint (PCC) node A may delegate the
forward LSP1 and reverse LSP2 to the PCE. forward LSP1 and reverse LSP2 to the PCE.
The originating endpoint node A reports tunnels 1 and forward LSP1 and re verse LSP2 The originating endpoint node A reports Tunnel 1 and forward LSP1 and rev erse LSP2
to the PCE. The endpoint (PCC) node D reports to the PCE. The endpoint (PCC) node D reports
tunnel 2 and LSP2 to the PCE. Tunnel 2 and LSP2 to the PCE.
</t> </t>
</section>
</section>
</section> </section>
<section anchor="sect-3.2" numbered="true" toc="default">
<section anchor="sect-3.2" title="Double-sided Initiation"> <name>Double-Sided Initiation</name>
<t>As specified in <xref target="RFC7551"/>, in the double-sided case, <t>As specified in <xref target="RFC7551" format="default"/>, in the dou
ble-sided case,
the bidirectional tunnel is provisioned on both endpoint nodes (PCCs) the bidirectional tunnel is provisioned on both endpoint nodes (PCCs)
of the tunnel. The forward and reverse LSPs of this tunnel are of the tunnel. The forward and reverse LSPs of this tunnel are
initiated with the Association Type set to "Double-sided Bidirectional initiated with the Association Type set to "Double-Sided Bidirectional
LSP Association" on both endpoint nodes. The forward and reverse LSPs LSP Association" on both endpoint nodes. The forward and reverse LSPs
are identified in the "Bidirectional LSP Association Group TLV" of their are identified in the Bidirectional LSP Association Group TLV of their
ASSOCIATION Objects.</t> ASSOCIATION objects.</t>
<t>As specified in <xref target="RFC8537" format="default"/>, for fast r
<t>As specified in <xref target="RFC8537"/>, for fast reroute bypass eroute bypass
tunnel assignment, the LSP with the higher Source Address <xref tunnel assignment, the LSP with the higher source address <xref target="
target="RFC3209"/> is identified as the forward LSP of the RFC3209" format="default"/> is identified as the forward LSP of the
double-sided initiated bidirectional LSP.</t> double-sided initiated bidirectional LSP.</t>
<section anchor="sect-3.2.1" numbered="true" toc="default">
<section anchor="sect-3.2.1" title="PCE-Initiated Double-sided Bidirectiona <name>PCE-Initiated Double-Sided Bidirectional LSP</name>
l LSP"> <figure anchor="ure-example-of-pce-initiated-double-sided-bidirectiona
l-lsp">
<figure anchor="ure-example-of-pce-initiated-double-sided-bidirectional- <name>Example of PCE-Initiated Double-Sided Bidirectional LSP</name>
lsp" <artwork name="" type="" align="left" alt=""><![CDATA[
title="Example of PCE-Initiated Double-sided Bidirectional LSP">
<artwork>
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Initiates: | \ Initiates: Initiates: | \ Initiates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, 0)) | \ (LSP2 (F, 0)) (LSP1 (F, 0)) | \ (LSP2 (F, 0))
Association #3 v v Association #3 Association #3 v v Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
skipping to change at line 324 skipping to change at line 263
| PCE | | PCE |
+-----+ +-----+
Reports: ^ ^ Reports: Reports: ^ ^ Reports:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #3 | \ Association #3 Association #3 | \ Association #3
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, (0,P4,P5)=PLSP-IDs Legend: F = Forward LSP, (0,P4,P5) = PLSP-IDs
</artwork> ]]></artwork>
</figure> </figure>
<t>Using partial topology from Figure 1, as shown in Figure 4, the forwa <t>Using partial topology from <xref target="ure-example-of-associated
rd tunnel 1 and forward LSP1 -bidirectional-lsp"/>, as shown in <xref target="ure-example-of-pce-initiated-do
are initiated on the endpoint node A and the reverse tunnel 2 and uble-sided-bidirectional-lsp"/>, the forward Tunnel 1 and forward LSP1
are initiated on the endpoint node A, and the reverse Tunnel 2 and
reverse LSP2 are initiated on the endpoint node D by the PCE. reverse LSP2 are initiated on the endpoint node D by the PCE.
The PLSP-IDs used are P4 on the endpoint node A The PLSP-IDs used are P4 on the endpoint node A
and P5 on the endpoint node D. and P5 on the endpoint node D.
The endpoint node A (PCC) reports the forward LSP1 and endpoint node D r The endpoint node A (PCC) reports the forward LSP1, and endpoint node D
eports the forward LSP2 to the PCE. reports the forward LSP2 to the PCE.
</t> </t>
</section>
</section> <section anchor="sect-3.2.2" numbered="true" toc="default">
<name>PCC-Initiated Double-Sided Bidirectional LSP</name>
<section anchor="sect-3.2.2" title="PCC-Initiated Double-sided Bidirectiona <figure anchor="ure-example-of-pcc-initiated-double-sided-bidirectiona
l LSP"> l-lsp">
<name>Example of PCC-Initiated Double-Sided Bidirectional LSP</name>
<figure anchor="ure-example-of-pcc-initiated-double-sided-bidirectional-l <artwork name="" type="" align="left" alt=""><![CDATA[
sp"
title="Example of PCC-Initiated Double-sided Bidirectional LSP">
<artwork>
+-----+ +-----+
| PCE | | PCE |
+-----+ +-----+
Reports/Delegates: ^ ^ Reports/Delegates: Reports/Delegates: ^ ^ Reports/Delegates:
Tunnel 1 (F) | \ Tunnel 2 (F) Tunnel 1 (F) | \ Tunnel 2 (F)
(LSP1 (F, P4)) | \ (LSP2 (F, P5)) (LSP1 (F, P4)) | \ (LSP2 (F, P5))
Association #4 | \ Association #4 Association #4 | \ Association #4
+-----+ +-----+ +-----+ +-----+
| A | | D | | A | | D |
+-----+ +-----+ +-----+ +-----+
Legends: F=Forward LSP, (P4,P5)=PLSP-IDs Legend: F = Forward LSP, (P4,P5) = PLSP-IDs
</artwork> ]]></artwork>
</figure> </figure>
<t>Using partial topology from <xref target="ure-example-of-associated
<t>Using partial topology from Figure 1, as shown in Figure 5, the forwar -bidirectional-lsp"/>, as shown in <xref target="ure-example-of-pcc-initiated-do
d tunnel 1 and forward LSP1 uble-sided-bidirectional-lsp"/>, the forward Tunnel 1 and forward LSP1
are initiated on the endpoint node A and the reverse tunnel 2 and are initiated on the endpoint node A, and the reverse Tunnel 2 and
reverse LSP2 are initiated on the endpoint node D (the PCCs). reverse LSP2 are initiated on the endpoint node D (the PCCs).
The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint n ode D. The PLSP-IDs used are P4 on the endpoint node A and P5 on the endpoint n ode D.
Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to the PCE. Both endpoint (PCC) nodes may delegate the forward LSP1 and LSP2 to the PCE.
The endpoint node A (PCC) reports the forward LSP1 and endpoint node D r The endpoint node A (PCC) reports the forward LSP1, and endpoint node D
eports the forward LSP2 to the PCE. reports the forward LSP2 to the PCE.
</t> </t>
</section>
</section>
</section> </section>
<section anchor="sect-3.3" numbered="true" toc="default">
<section anchor="sect-3.3" <name>Co-routed Associated Bidirectional LSP</name>
title="Co-routed Associated Bidirectional LSP">
<t>In both single-sided and double-sided initiation cases, forward and <t>In both single-sided and double-sided initiation cases, forward and
reverse LSPs can be co-routed as shown in Figure 6, where both forward reverse LSPs can be co-routed as shown in <xref target="ure-example-of-c o-routed-associated-bidirectional-lsp"/>, where both forward
and reverse LSPs of a bidirectional LSP follow the same congruent path and reverse LSPs of a bidirectional LSP follow the same congruent path
in the forward and reverse directions, respectively.</t> in the forward and reverse directions, respectively.</t>
<figure anchor="ure-example-of-co-routed-associated-bidirectional-lsp">
<figure anchor="ure-example-of-co-routed-associated-bidirectional-lsp" <name>Example of Co-routed Associated Bidirectional LSP</name>
title="Example of Co-routed Associated Bidirectional LSP"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork> LSP3 --> LSP3 --> LSP3 -->
LSP3 --&gt; LSP3 --&gt; LSP3 --&gt;
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| A +-----------+ B +-----------+ C +-----------+ D | | A +-----------+ B +-----------+ C +-----------+ D |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
&lt;-- LSP4 &lt;-- LSP4 &lt;-- LSP4 <-- LSP4 <-- LSP4 <-- LSP4
</artwork> ]]></artwork>
</figure> </figure>
<t>The procedure specified in <xref target="RFC8537"/> for fast reroute
<t>The procedure specified in [RFC8537] for fast reroute bypass tunnel bypass tunnel
assignment is also applicable to the Co-routed Associated Bidirectional LSPs assignment is also applicable to the co-routed associated bidirectional LSPs
.</t> .</t>
</section>
</section> <section anchor="sect-3.4" numbered="true" toc="default">
<name>Summary of PCEP Extensions</name>
<section anchor="sect-3.4" title="Summary of PCEP Extensions"><t> <t>
The PCEP extensions defined in this document cover the following modes of The PCEP extensions defined in this document cover the following modes of
operations under the stateful PCE model:</t> operation under the stateful PCE model:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>A PCC initiates the forward and reverse LSP of a single-sided
<t>A PCC initiates the forward and reverse LSP of a Single-sided bidirectional LSP and retains control of the
Bidirectional LSP and retains the control of the
LSPs. Similarly, both PCCs initiate the forward LSPs of a LSPs. Similarly, both PCCs initiate the forward LSPs of a
Double-sided Bidirectional LSP and retain the control of the double-sided bidirectional LSP and retain control of the
LSPs. The PCC computes the path itself or makes a request for path LSPs. The PCC computes the path itself or makes a request for path
computation to a PCE. After the path setup, it reports the computation to a PCE. After the path setup, it reports the
information and state of the path to the PCE. This includes the information and state of the path to the PCE. This includes the
association group identifying the bidirectional LSP. This is the association group identifying the bidirectional LSP. This is the
Passive Stateful mode defined in <xref target="RFC8051"/>.</t> passive stateful mode defined in <xref target="RFC8051" format="defaul
t"/>.</li>
<t>A PCC initiates the forward and reverse LSP of a Single-sided <li>A PCC initiates the forward and reverse LSP of a single-sided
Bidirectional LSP and delegates the control of the bidirectional LSP and delegates control of the
LSPs to a Stateful PCE. Similarly, both PCCs initiate the forward LSPs LSPs to a stateful PCE. Similarly, both PCCs initiate the forward LSPs
of a of a
Double-sided Bidirectional LSP and delegate the control of the double-sided bidirectional LSP and delegate control of the
LSPs to a Stateful PCE. During delegation the association group LSPs to a stateful PCE. During delegation, the association group
identifying the bidirectional LSP is included. The PCE computes the identifying the bidirectional LSP is included. The PCE computes the
path of the LSP and updates the PCC with the information about the path of the LSP and updates the PCC with the information about the
path as long as it controls the LSP. This is the Active Stateful path as long as it controls the LSP. This is the active stateful
mode defined in <xref target="RFC8051"/>.</t> mode defined in <xref target="RFC8051" format="default"/>.</li>
<li>A PCE initiates the forward and reverse LSP of a single-sided
<t>A PCE initiates the forward and reverse LSP of a Single-sided bidirectional LSP on a PCC and retains control
Bidirectional LSP on a PCC and retains the control
of the LSP. Similarly, a PCE initiates the forward LSPs of a of the LSP. Similarly, a PCE initiates the forward LSPs of a
Double-sided Bidirectional LSP on both PCCs and retains the control double-sided bidirectional LSP on both PCCs and retains control
of the LSPs. The PCE is responsible for computing the path of the LSP of the LSPs. The PCE is responsible for computing the path of the LSP
and updating the PCC with the information about the path as well as and updating the PCC with the information about the path as well as
the association group identifying the bidirectional LSP. This is the the association group identifying the bidirectional LSP. This is the
PCE-Initiated mode defined in <xref target="RFC8281"/>.</t> PCE-initiated mode defined in <xref target="RFC8281" format="default"/
>.</li>
<t>A PCC requests co-routed or non-co-routed paths for forward and <li>A PCC requests co-routed or non-co-routed paths for forward and
reverse LSPs of a bidirectional LSP including when using a Stateless P reverse LSPs of a bidirectional LSP, including when using a stateless
CE <xref PCE <xref target="RFC5440" format="default"/>.</li>
target="RFC5440"/>.</t> </ul>
</list></t> </section>
</section> <section anchor="sect-3.5" numbered="true" toc="default">
<name>Operational Considerations</name>
<section anchor="sect-3.5" title="Operational Considerations"><t> <t>
The double-sided case has an advantage when compared to the single-sided The double-sided case has an advantage when compared to the single-sided
case summarized as following:</t> case, summarized as follows:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>In the double-sided case, two existing unidirectional LSPs in reve
<t>In double-sided case, two existing unidirectional LSPs in reverse rse
directions in the network can be associated to form a bidirectional LSP wi thout directions in the network can be associated to form a bidirectional LSP wi thout
significantly increasing the operational complexity.</t> significantly increasing the operational complexity.</li>
</list></t> </ul>
<t>The single-sided case has some advantages when compared to the double
<t>The single-sided case has some advantages when compared to the double-s -sided case, summarized as follows:</t>
ided case summarized as following:</t> <ul spacing="normal">
<li>Some Operations, Administration, and Maintenance (OAM) use cases
<t><list style="symbols">
<t>Some Operations, Administration, and Maintenance (OAM) use-cases
may require an endpoint node to know both forward and may require an endpoint node to know both forward and
reverse direction paths for monitoring the bidirectional LSP. For such us reverse paths for monitoring the bidirectional LSP. For such use cases, t
e-cases, he
single-sided case may be preferred.</t> single-sided case may be preferred.</li>
<li>For co-routed associated bidirectional LSPs in PCC-initiated mode,
<t>For Co-routed Associated Bidirectional LSPs in PCC initiated mode,
the single-sided case allows the originating PCC to dynamically compute the single-sided case allows the originating PCC to dynamically compute
co-routed forward and reverse paths. This may not be possible with double co-routed forward and reverse paths. This may not be possible with the do
-sided uble-sided
case where the forward and reverse direction paths are computed case where the forward and reverse paths are computed
separately as triggered by two different PCCs.</t> separately as triggered by two different PCCs.</li>
<li>The associated bidirectional LSPs in the single-sided case can be
<t>The Associated Bidirectional LSPs with single-sided case can be deploy deployed
ed in a network where PCEP is only enabled on the originating endpoint nodes
in a network where PCEP is only enabled on the originating endpoint nodes as
as remote endpoint nodes create the reverse tunnels using RSVP-TE Path me remote endpoint nodes create the reverse tunnels using RSVP-TE Path messa
ssages.</t> ges.</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section anchor="sect-4" title="Protocol Extensions"> <name>Protocol Extensions</name>
<section anchor="sect-4.1" title="ASSOCIATION Object"> <section anchor="sect-4.1" numbered="true" toc="default">
<t>As per <xref target="RFC8697"/>, LSPs are associated by adding them <name>ASSOCIATION Object</name>
<t>As per <xref target="RFC8697" format="default"/>, LSPs are associated
by adding them
to a common association group. This document defines two new Association Types, called to a common association group. This document defines two new Association Types, called
"Single-sided Bidirectional LSP" (TBD1) and "Double-sided "Single-Sided Bidirectional LSP Association" (4) and "Double-Sided
Bidirectional LSP" (TBD2), using the generic ASSOCIATION Bidirectional LSP Association" (5), using the generic ASSOCIATION
Object ((Object-Class value 40). object (Object-Class value 40).
A member of the Bidirectional LSP Association A member of the Bidirectional LSP Association
can take the role of a forward or reverse LSP and follows the following rules:</t> can take the role of a forward or reverse LSP and follows the following rules:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>An LSP (forward or reverse) <bcp14>MUST NOT</bcp14> be part of mor
<t>An LSP (forward or reverse) MUST NOT be part of more than one e than one
Bidirectional LSP Association.</t> Bidirectional LSP Association.</li>
<li>The LSPs in a Bidirectional LSP Association <bcp14>MUST</bcp14> ha
<t>The LSPs in a Bidirectional LSP Association MUST have matching endpo ve matching endpoint
int nodes in the reverse directions.</li>
nodes in the reverse directions.</t> <li>The same tunnel (as defined in <xref target="RFC3209"
sectionFormat="of" section="2.1"/>) <bcp14>MUST</bcp14> contain the
<t>The Tunnel (as defined in Section 2.1 of <xref target="RFC3209"/>) c forward and reverse LSPs of the Single-Sided Bidirectional LSP
ontaining the Association on the originating node, albeit both LSPs have reversed
forward and reverse LSPs of the Single-sided Bidirectional LSP Associat endpoint nodes.</li>
ion </ul>
on the originating node MUST be the same, <t>The Bidirectional LSP Association Types are considered to be both dyn
albeit both LSPs have reversed endpoint nodes.</t> amic and
</list></t> operator configured in nature. As per <xref target="RFC8697"/>, the ass
ociation group could
<t>The Bidirectional LSP Association types are considered to be both dyn
amic and
operator-configured in nature. As per [RFC8697], the association group
could
be manually created by the operator on the PCEP peers, and the LSPs be manually created by the operator on the PCEP peers, and the LSPs
belonging to this association are conveyed via PCEP messages to the belonging to this association are conveyed via PCEP messages to the
PCEP peer; alternately, the association group could be created PCEP peer; alternately, the association group could be created
dynamically by the PCEP speaker, and both the association group dynamically by the PCEP speaker, and both the association group
information and the LSPs belonging to the association group are information and the LSPs belonging to the association group are
conveyed to the PCEP peer. The Operator-configured Association Range conveyed to the PCEP peer. The operator-configured Association Range
MUST be set for this association-type to mark a range of Association <bcp14>MUST</bcp14> be set for this Association Type to mark a range of
Association
Identifiers that are used for operator-configured associations to Identifiers that are used for operator-configured associations to
avoid any Association Identifier clash within the scope of the avoid any Association Identifier clash within the scope of the
Association Source (Refer to <xref target="RFC8697"/>).</t> Association Source (refer to <xref target="RFC8697" format="default"/>).
</t>
<t>Specifically, for the PCE Initiated Bidirectional LSPs, these Associa <t>Specifically, for the PCE-initiated bidirectional LSPs, these associa
tions tions
are dynamically created by the PCE on the PCE peers. Similarly, are dynamically created by the PCE on the PCE peers. Similarly,
for both PCE Initiated and PCC Initiated single-sided case, for both the PCE-initiated and the PCC-initiated single-sided cases,
these associations are also dynamically created on the these associations are also dynamically created on the
remote endpoint node using the information remote endpoint node using the information
received from the RSVP message from the originating node.</t> received from the RSVP message from the originating node.</t>
<t>The Association ID, Association Source, optional Global Association <t>The Association ID, Association Source, optional Global Association
Source TLV and optional Extended Association ID TLV in the Bidirectional Source TLV, and optional Extended Association ID TLV in the Bidirectiona
LSP l LSP
Association Object are initialized using the procedures defined ASSOCIATION object are initialized using the procedures defined
in <xref target="RFC8697"/> and <xref target="RFC7551"/>.</t> in <xref target="RFC8697" format="default"/> and <xref target="RFC7551"
format="default"/>.</t>
<t><xref target="RFC8697"/> specifies the mechanism for the capability a <t><xref target="RFC8697" format="default"/> specifies the mechanism for
dvertisement of the capability advertisement of
the Association Types supported by a PCEP speaker by defining an the Association Types supported by a PCEP speaker by defining an
ASSOC-Type-List TLV to be carried within an OPEN Object. This ASSOC-Type-List TLV to be carried within an OPEN object. This
capability exchange for the Bidirectional LSP Association Types MUST be capability exchange for the Bidirectional LSP Association Types <bcp14>M
UST</bcp14> be
done before using the Bidirectional LSP Association. Thus, the PCEP done before using the Bidirectional LSP Association. Thus, the PCEP
speaker MUST include the Bidirectional LSP Association Types in the speaker <bcp14>MUST</bcp14> include the Bidirectional LSP Association Ty
ASSOC-Type-List TLV and MUST receive the same from the PCEP peer pes in the
ASSOC-Type-List TLV and <bcp14>MUST</bcp14> receive the same from the PC
EP peer
before using the Bidirectional LSP Association in PCEP messages.</t> before using the Bidirectional LSP Association in PCEP messages.</t>
</section> </section>
<section anchor="sect-4.2" numbered="true" toc="default">
<section anchor="sect-4.2" <name>Bidirectional LSP Association Group TLV</name>
title="Bidirectional LSP Association Group TLV"> <t>The Bidirectional LSP Association Group TLV is an <bcp14>OPTIONAL</bc
<t>The "Bidirectional LSP Association Group TLV" is an OPTIONAL TLV for p14> TLV for use with
use with the Bidirectional LSP Associations (ASSOCIATION object with Association
Bidirectional LSP Associations (ASSOCIATION Object with Association Type 4 for Single-Sided Bidirectional LSP Association or 5 for Double-Si
Type TBD1 for Single-sided Bidirectional LSP or TBD2 for Double-sided Bi ded Bidirectional LSP Association).</t>
directional LSP).</t> <ul spacing="normal">
<li>The Bidirectional LSP Association Group TLV follows the PCEP
<t><list style="symbols"> TLV format from <xref target="RFC5440" format="default"/>.</li>
<t>The "Bidirectional LSP Association Group TLV" follows the PCEP <li>The Type (16 bits) of the TLV is 54.</li>
TLV format from <xref target="RFC5440"/>.</t> <li>The Length is 4 bytes.</li>
<li>The value comprises of a single field, the
<t>The Type (16 bits) of the TLV is TBD3, to be assigned by Flags field (32 bits), where each bit represents a flag
IANA.</t> option.</li>
<li>If the Bidirectional LSP Association Group TLV is missing, it
<t>The Length is 4 Bytes.</t> means the LSP is the forward LSP, and it is not a co-routed LSP.</li
>
<t>The value comprises of a single field, the Bidirectional LSP <li>When the Bidirectional LSP Association Group TLV is present, the R
Association Flag (32 bits), where each bit represents a flag flag <bcp14>MUST</bcp14> be reset for the forward LSP for both co-ro
option.</t> uted and non-co-routed LSPs.</li>
<li>For co-routed LSPs, this TLV <bcp14>MUST</bcp14> be present and th
<t>If the "Bidirectional LSP Association Group TLV" is missing, it e C flag set.</li>
means the LSP is the forward LSP and it is not co-routed LSP.</t> <li>For reverse LSPs, this TLV <bcp14>MUST</bcp14> be present and the
R flag set.</li>
<t>When "Bidirectional LSP Association Group TLV" is present, the R <li>The Bidirectional LSP Association Group TLV <bcp14>MUST NOT</bcp14
flag MUST be reset for the forward LSP for both co-routed and non co > be present
-routed LSPs.</t>
<t>For co-routed LSPs, this TLV MUST be present and C flag set.</t>
<t>For reverse LSPs, this TLV MUST be present and R flag set.</t>
<t>The "Bidirectional LSP Association Group TLV" MUST NOT be present
more than once. If it appears more than once, only the first more than once. If it appears more than once, only the first
occurrence is processed and any others MUST be ignored.</t> occurrence is processed, and any others <bcp14>MUST</bcp14> be ignor
</list></t> ed.</li>
</ul>
<t>The format of the "Bidirectional LSP Association Group TLV" is shown <t>The format of the Bidirectional LSP Association Group TLV is shown
in Figure 7:</t> in <xref target="ure-bidirectional-lsp-association-group-tlv-format"/>.<
/t>
<figure anchor="ure-bidirectional-lsp-association-group-tlv-format" <figure anchor="ure-bidirectional-lsp-association-group-tlv-format">
title="Bidirectional LSP Association Group TLV format"> <name>Bidirectional LSP Association Group TLV Format</name>
<artwork> <artwork name="" type="" align="left" alt=""><![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 = TBD3 | Length | | Type = 54 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |C|R| | Flags |C|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
</figure> </figure>
<t>Flags for the Bidirectional LSP Association Group TLV are defined as
<t>Flags for "Bidirectional LSP Association Group TLV" are defined as fo follows.</t>
llowing.</t> <dl>
<dt>R (Reverse LSP, 1 bit, bit number 31):</dt><dd>Indicates whether the LSP ass
<t>R (Reverse LSP, 1 bit, Bit number 31) - Indicates whether the LSP ass ociated is
ociated is
the reverse LSP of the bidirectional LSP. If this flag is set, the LSP the reverse LSP of the bidirectional LSP. If this flag is set, the LSP
is a reverse LSP. If this flag is not set, the LSP is a forward LSP.</t> is a reverse LSP. If this flag is not set, the LSP is a forward LSP.</dd
>
<t>C (Co-routed Path, 1 bit, Bit number 30) - Indicates whether the bidi
rectional LSP
is co-routed. This flag MUST be set for both the forward and reverse
LSPs of a co-routed bidirectional LSP.</t>
<t>The C flag is used by the PCE (for both Stateful and Stateless) to <dt>C (Co-routed Path, 1 bit, bit number 30):</dt><dd>Indicates whether the bidi
rectional LSP
is co-routed. This flag <bcp14>MUST</bcp14> be set for both the forward
and reverse
LSPs of a co-routed bidirectional LSP.</dd>
</dl>
<t>The C flag is used by the PCE (both stateful and stateless) to
compute bidirectional paths of the forward and reverse LSPs of a compute bidirectional paths of the forward and reverse LSPs of a
co-routed bidirectional LSP.</t> co-routed bidirectional LSP.</t>
<t>The unassigned flags (bit numbers 0-29) <bcp14>MUST</bcp14> be set to
<t>The unassigned flags (Bit Number 0-29) MUST be set to 0 when sent and 0 when sent and <bcp14>MUST</bcp14> be ignored
MUST be ignored
when received.</t> when received.</t>
</section> </section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
<section anchor="sect-5" title="PCEP Procedure"> <name>PCEP Procedure</name>
<t>The PCEP procedure defined in this document is applicable to the foll <t>The PCEP procedure defined in this document is applicable to the follow
owing three scenarios:</t> ing three scenarios:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Neither unidirectional LSP exists, and both must be established.</li
<t>Neither unidirectional LSP exists, and both must be established.</t >
> <li>Both unidirectional LSPs exist, but the association must be establis
<t>Both unidirectional LSPs exist, but the association must be establi hed.</li>
shed.</t> <li>One LSP exists, but the reverse associated LSP must be established.<
<t>One LSP exists, but the reverse associated LSP must be established. /li>
</t> </ul>
</list></t> <section anchor="sect-5.1" numbered="true" toc="default">
<name>PCE-Initiated LSPs</name>
<section anchor="sect-5.1" title="PCE Initiated LSPs"> <t>As specified in <xref target="RFC8697" format="default"/>, Bidirectio
<t>As specified in <xref target="RFC8697"/>, the Bidirectional LSP nal LSP
Associations can be created and updated by a Stateful PCE.</t> Associations can be created and updated by a stateful PCE.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>For a Single-Sided Bidirectional LSP Association initiated by the
<t>For Single-sided Bidirectional LSP Association initiated by the PCE, PCE,
it MUST send PCInitiate message to the originating endpoint node with bo the PCE <bcp14>MUST</bcp14> send a PCInitiate message to the originating
th endpoint node with both forward and reverse LSPs. For a Double-Sided Bidirectio
direction LSPs. For Double-sided Bidirectional LSP Association nal LSP Association
initiated by the PCE, it MUST send PCInitiate message to both initiated by the PCE, it <bcp14>MUST</bcp14> send a PCInitiate message t
endpoint nodes with forward direction LSPs. </t> o both
endpoint nodes with forward LSPs. </li>
<t>Both PCCs MUST report the forward and reverse LSPs in the <li>Both PCCs <bcp14>MUST</bcp14> report the forward and reverse LSPs
Bidirectional LSP Association to the PCE. PCC reports via PCRpt mess in the
age.</t> Bidirectional LSP Association to the PCE. A PCC reports via a PCRpt
message.</li>
<t>Stateful PCEs MAY create and update the forward and reverse LSPs <li>Stateful PCEs <bcp14>MAY</bcp14> create and update the forward and
independently for the Single-sided Bidirectional reverse LSPs
LSP Association on the originating endpoint node.</t> independently for the Single-Sided Bidirectional
LSP Association on the originating endpoint node.</li>
<t>Stateful PCEs MAY create and update the forward LSP <li>Stateful PCEs <bcp14>MAY</bcp14> create and update the forward LSP
independently for the Double-sided Bidirectional independently for the Double-Sided Bidirectional
LSP Association on the endpoint nodes.</t> LSP Association on the endpoint nodes.</li>
<li>Stateful PCEs establish and remove the association
<t>Stateful PCEs establish and remove the association relationship on a per-LSP basis.</li>
relationship on a per LSP basis.</t> <li>Stateful PCEs create and update the LSP and the association
<t>Stateful PCEs create and update the LSP and the association
on PCCs via PCInitiate and PCUpd messages, respectively, using on PCCs via PCInitiate and PCUpd messages, respectively, using
the procedures described in <xref target="RFC8697"/>.</t> the procedures described in <xref target="RFC8697" format="default"/
</list></t> >.</li>
</ul>
</section> </section>
<section anchor="sect-5.2" numbered="true" toc="default">
<section anchor="sect-5.2" title="PCC Initiated LSPs"> <name>PCC-Initiated LSPs</name>
<t>As specified in <xref target="RFC8697"/>, the Bidirectional LSP <t>As specified in <xref target="RFC8697" format="default"/>, Bidirectio
nal LSP
Associations can also be created and updated by a PCC.</t> Associations can also be created and updated by a PCC.</t>
<ul spacing="normal">
<t><list style="symbols"> <li>For a Single-Sided Bidirectional LSP Association initiated at a PC
<t>For Single-sided Bidirectional LSP Association initiated at a PCC, C,
it MUST send PCRpt message to the PCE with both direction LSPs. the PCC <bcp14>MUST</bcp14> send a PCRpt message to the PCE with both fo
For Double-sided Bidirectional LSP Association initiated at the PCCs, rward and reverse LSPs.
both PCCs MUST send PCRpt message to the PCE with forward direction LSPs For a Double-Sided Bidirectional LSP Association initiated at the PCCs,
.</t> both PCCs <bcp14>MUST</bcp14> send a PCRpt message to the PCE with forwa
rd LSPs.</li>
<t>PCCs on the originating endpoint node MAY create and update the f <li>PCCs on the originating endpoint node <bcp14>MAY</bcp14> create an
orward and reverse LSPs d update the forward and reverse LSPs
independently for the Single-sided Bidirectional LSP Association.</t independently for the Single-Sided Bidirectional LSP Association.</l
> i>
<li>PCCs on the endpoint nodes <bcp14>MAY</bcp14> create and update th
<t>PCCs on the endpoint nodes MAY create and update the forward LSP e forward LSP
independently for the Double-sided Bidirectional LSP Association.</t independently for the Double-Sided Bidirectional LSP Association.</l
> i>
<li>PCCs establish and remove the association group on a
<t>PCCs establish and remove the association group on a per-LSP basis. PCCs <bcp14>MUST</bcp14> report the change in the ass
per LSP basis. PCCs MUST report the change in the association group ociation group of an LSP
of an LSP to PCE(s) via a PCRpt message.</li>
to PCE(s) via PCRpt message.</t> <li>PCCs report the forward and reverse LSPs in the Bidirectional LSP
Association independently to
<t>PCCs report the forward and reverse LSPs in the Bidirectional LSP PCE(s) via a PCRpt message.</li>
Association independently to <li>PCCs for the single-sided case <bcp14>MAY</bcp14> delegate the for
PCE(s) via PCRpt message.</t> ward and reverse LSPs independently to
a stateful PCE, where the PCE would control the LSPs. In this case,
<t>PCCs for the single-sided case MAY delegate the forward and rever the originating (PCC) endpoint node <bcp14>SHOULD</bcp14> delegate b
se LSPs independently to oth forward and reverse
a Stateful PCE, where PCE would control the LSPs. In this case, LSPs of a tunnel together to a stateful PCE in order to avoid any ra
the originating (PCC) endpoint node SHOULD delegate both forward and ce condition.</li>
reverse <li>PCCs for the double-sided case <bcp14>MAY</bcp14> delegate the for
LSPs of a tunnel together to a Stateful PCE in order to avoid any ra ward LSPs to
ce condition.</t> a stateful PCE, where the PCE would control the LSPs.</li>
<li>A stateful PCE updates the LSPs in the Bidirectional LSP
<t>PCCs for the double-sided case MAY delegate the forward LSPs to Association via a PCUpd message, using the procedures
a Stateful PCE, where PCE would control the LSPs.</t> described in <xref target="RFC8697" format="default"/>.</li>
</ul>
<t>Stateful PCE updates the LSPs in the Bidirectional LSP
Association via PCUpd message, using the procedures
described in <xref target="RFC8697"/>.</t>
</list></t>
</section> </section>
<section anchor="sect-5.3" numbered="true" toc="default">
<section anchor="sect-5.3" title="Stateless PCE"> <name>Stateless PCE</name>
<t>For a stateless PCE, it might be useful to associate a path <t>For a stateless PCE, it might be useful to associate a path computati
computation request to an association group, thus enabling it to on request to an association group, thus enabling it to
associate a common set of configuration parameters or behaviors with associate a common set of configuration parameters or behaviors with
the request <xref target="RFC8697"/>. A PCC can request co-routed or non the request <xref target="RFC8697" format="default"/>. A PCC can request
-co-routed forward and co-routed or non-co-routed forward and
reverse direction paths from a stateless PCE for a Bidirectional LSP Ass reverse paths from a stateless PCE for a Bidirectional LSP Association.<
ociation.</t> /t>
</section> </section>
<section anchor="sect-5.4" numbered="true" toc="default">
<section anchor="sect-5.4" title="Bidirectional (B) Flag"> <name>Bidirectional (B) Flag</name>
<t>As defined in <xref target="RFC5440"/>, the Bidirectional (B) flag <t>As defined in <xref target="RFC5440" format="default"/>, the Bidirect
in the Request Parameters (RP) Object is set when the PCC specifies ional (B) flag
in the Request Parameters (RP) object is set when the PCC specifies
that the path computation request is for a bidirectional TE LSP with the that the path computation request is for a bidirectional TE LSP with the
same TE requirements in each direction. For an same TE requirements in each direction. For an
associated bidirectional LSP, the B-flag is also set when the PCC makes associated bidirectional LSP, the B flag is also set when the PCC makes
the path computation request for the same TE requirements for the the path computation request for the same TE requirements for the
forward and reverse direction LSPs.</t> forward and reverse LSPs.</t>
<t>Note that the B flag defined in a Stateful PCE Request Parameter (SRP
<t>Note that the B-flag defined in Stateful PCE Request Parameter (SRP) )
Object <xref target="I-D.ietf-pce-pcep-stateful-pce-gmpls"/> to object <xref target="I-D.ietf-pce-pcep-stateful-pce-gmpls" format="defau
indicate 'bidirectional co-routed LSP' is used for GMPLS signaled bidire lt"/> to
ctional LSPs indicate "bidirectional co-routed LSP" is used for GMPLS-signaled bidire
ctional LSPs
and is not applicable to the associated bidirectional LSPs.</t> and is not applicable to the associated bidirectional LSPs.</t>
</section> </section>
<section anchor="sect-5.5" numbered="true" toc="default">
<section anchor="sect-5.5" title="PLSP-ID Usage"> <name>PLSP-ID Usage</name>
<t>As defined in <xref target="RFC8231"/>, a PCEP-specific LSP <t>As defined in <xref target="RFC8231" format="default"/>, a PCEP-speci
Identifier (PLSP-ID) is created by a PCC to uniquely identify an LSP fic LSP
Identifier (PLSP-ID) is created by a PCC to uniquely identify an LSP,
and it remains the same for the lifetime of a PCEP session.</t> and it remains the same for the lifetime of a PCEP session.</t>
<t>In the case of a Single-Sided Bidirectional LSP Association, the reve
<t>In case of Single-sided Bidirectional LSP Association, the reverse rse
LSP of a bidirectional LSP created on the originating endpoint node is LSP of a bidirectional LSP created on the originating endpoint node is
identified by the PCE using 2 different PLSP-IDs based on the PCEP identified by the PCE using two different PLSP-IDs, based on the PCEP
session on the ingress or egress node PCCs for the LSP. In other words, session on the ingress or egress node PCCs for the LSP. In other words,
the LSP will have a PLSP-ID P2 allocated at the the LSP will have a PLSP-ID P2 allocated at the
ingress node PCC while it will have a PLSP-ID P3 allocated at the egress ingress node PCC, while it will have a PLSP-ID P3 allocated at the egres
node PCC s node PCC
(as shown in Figure 2 and Figure 3). There is no change in the PLSP-ID (as shown in Figures <xref target="ure-example-of-pce-initiated-single-s
allocation procedure for the forward LSP of a Single-sided ided-bidirectional-lsp" format="counter" /> and <xref target="ure-example-of-pcc
Bidirectional LSP created on the originating endpoint node.</t> -initiated-single-sided-bidirectional-lsp" format="counter"/>). There is no cha
nge in the PLSP-ID
<t>In case of Double-sided Bidirectional LSP allocation procedure for the forward LSP of a single-sided
bidirectional LSP created on the originating endpoint node.</t>
<t>In the case of a Double-Sided Bidirectional LSP
Association, there is no change in the PLSP-ID allocation Association, there is no change in the PLSP-ID allocation
procedure for the forward LSPs on both PCCs.</t> procedure for the forward LSPs on either PCC.</t>
<t>For an associated bidirectional LSP, the LSP-IDENTIFIERS TLV <xref ta
<t>For an Associated Bidirectional LSP, LSP-IDENTIFIERS TLV <xref rget="RFC8231" format="default"/> <bcp14>MUST</bcp14> be included in all forward
target="RFC8231"/> MUST be included in all forward and reverse and reverse
LSPs.</t> LSPs.</t>
</section> </section>
<section anchor="sect-5.6" numbered="true" toc="default">
<section anchor="sect-5.6" title="State Synchronization"> <name>State Synchronization</name>
<t>During state synchronization, a PCC MUST report all the existing <t>During state synchronization, a PCC <bcp14>MUST</bcp14> report all th
Bidirectional LSP Associations to the Stateful PCE as per <xref e existing
target="RFC8697"/>. After the state synchronization, the PCE MUST Bidirectional LSP Associations to the stateful PCE, as per <xref target=
"RFC8697" format="default"/>. After the state synchronization, the PCE <bcp14>M
UST</bcp14>
remove all previous remove all previous
Bidirectional LSP Associations absent in the report.</t> Bidirectional LSP Associations absent in the report.</t>
</section> </section>
<section anchor="sect-5.7" numbered="true" toc="default">
<section anchor="sect-5.7" title="Error Handling"> <name>Error Handling</name>
<t>If a PCE speaker receives an LSP with a <t>If a PCE speaker receives an LSP with a
Bidirectional LSP Association Type that it does not support, Bidirectional LSP Association Type that it does not support,
the PCE speaker MUST send PCErr with Error-Type = the PCE speaker <bcp14>MUST</bcp14> send PCErr with Error-Type =
26 (Association Error) and Error-Value = 1 (Association Type 26 (Association Error) and Error-value = 1 (Association Type
is not supported).</t> is not supported).</t>
<t>An LSP (forward or reverse) cannot be part of more than one <t>An LSP (forward or reverse) cannot be part of more than one
Bidirectional LSP Association. If a PCE speaker receives an LSP Bidirectional LSP Association. If a PCE speaker receives an LSP
not complying to this rule, the PCE speaker MUST send PCErr with Error-T not complying to this rule, the PCE speaker <bcp14>MUST</bcp14> send PCE
ype = rr with Error-Type =
26 (Association Error) and Error-Value = TBD4 (Bidirectional LSP 26 (Association Error) and Error-value = 14 (Association group mismatch)
Association - Group Mismatch).</t> .</t>
<t>The LSPs (forward or reverse) in a Single-sided Bidirectional
Association MUST belong to the same TE Tunnel (as defined in
<xref target="RFC3209"/>). If a PCE speaker attempts to add an LSP in a
Single-sided Bidirectional LSP Association for a different
Tunnel, the PCE speaker MUST send PCErr with Error-Type = 26 (Associatio
n
Error) and Error-Value = TBD5 (Bidirectional Association - Tunnel
Mismatch).</t>
<t>The LSPs (forward or reverse) in a Single-Sided Bidirectional
Association <bcp14>MUST</bcp14> belong to the same TE tunnel (as defined
in
<xref target="RFC3209" format="default"/>). If a PCE speaker attempts to
add an LSP in a
Single-Sided Bidirectional LSP Association for a different
tunnel, the PCE speaker <bcp14>MUST</bcp14> send PCErr with Error-Type =
26 (Association
Error) and Error-value = 15 (Tunnel mismatch in the association group).<
/t>
<t>The PCEP Path Setup Type (PST) for RSVP-TE is set to <t>The PCEP Path Setup Type (PST) for RSVP-TE is set to
'Path is set up using the RSVP-TE signaling protocol' (Value 0) "Path is set up using the RSVP-TE signaling protocol" (Value 0)
<xref target="RFC8408"/>. If a PCEP speaker receives a <xref target="RFC8408" format="default"/>. If a PCEP speaker receives a
different PST value for the Bidirectional LSP Associations different PST value for the Bidirectional LSP Associations
defined in this document, the PCE speaker MUST return a PCErr message wi defined in this document, the PCE speaker <bcp14>MUST</bcp14> return a P
th Error-Type = CErr message with Error-Type =
26 (Association Error) and Error-Value = TBD6 (Bidirectional LSP 26 (Association Error) and Error-value = 16 (Path Setup Type not support
Association - Path Setup Type Not Supported).</t> ed).</t>
<t>A Bidirectional LSP Association cannot have both unidirectional <t>A Bidirectional LSP Association cannot have both unidirectional
LSPs identified as Reverse LSPs or both LSPs LSPs identified as reverse LSPs or both LSPs
identified as Forward LSPs. If a PCE speaker receives an LSP identified as forward LSPs. If a PCE speaker receives an LSP
not complying to this rule, the PCE speaker MUST send PCErr with Error-T not complying to this rule, the PCE speaker <bcp14>MUST</bcp14> send PCE
ype = rr with Error-Type =
26 (Association Error) and Error-Value = TBD7 (Bidirectional LSP 26 (Association Error) and Error-value = 17 (Bidirectional LSP direction
Association - Direction Mismatch).</t> mismatch).</t>
<t>A Bidirectional LSP Association cannot have one unidirectional <t>A Bidirectional LSP Association cannot have one unidirectional
LSP identified as co-routed and the other identified as non-co-routed. I f a PCE speaker receives an LSP LSP identified as co-routed and the other identified as non-co-routed. I f a PCE speaker receives an LSP
not complying to this rule, the PCE speaker MUST send PCErr with Error-T not complying to this rule, the PCE speaker <bcp14>MUST</bcp14> send PCE
ype = rr with Error-Type =
26 (Association Error) and Error-Value = TBD8 (Bidirectional LSP 26 (Association Error) and Error-value = 18 (Bidirectional LSP co-routed
Association - Co-routed Mismatch).</t> mismatch).</t>
<t>The unidirectional LSPs forming the Bidirectional <t>The unidirectional LSPs forming the Bidirectional
LSP Association MUST have matching endpoint nodes in the reverse directi ons. LSP Association <bcp14>MUST</bcp14> have matching endpoint nodes in the reverse directions.
If a PCE speaker receives an LSP If a PCE speaker receives an LSP
not complying to this rule, the PCE speaker MUST send PCErr with Error-T not complying to this rule, the PCE speaker <bcp14>MUST</bcp14> send PCE
ype = rr with Error-Type =
26 (Association Error) and Error-Value = TBD9 (Bidirectional LSP 26 (Association Error) and Error-value = 19 (Endpoint mismatch in the as
Association - Endpoint Mismatch).</t> sociation group).</t>
<t>The processing rules as specified in <xref target="RFC8697" section="
<t>The processing rules as specified in Section 6.4 of <xref 6.4" sectionFormat="of"/> continue to apply to the Association Types defined
target="RFC8697"/> continue to apply to the Association Types defined
in this document.</t> in this document.</t>
</section> </section>
</section> </section>
<section anchor="sect-7" numbered="true" toc="default">
<section anchor="sect-6" title="Implementation Status"> <name>Security Considerations</name>
<t>[Note to the RFC Editor - remove this section before publication, as <t>The security considerations described in <xref target="RFC5440" format=
well as remove the reference to RFC 7942.]</t> "default"/>,
<xref target="RFC8231" format="default"/>, and <xref target="RFC8281" form
<t>This section records the status of known implementations of the at="default"/> apply to 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 anchor="sect-6.1" title="Implementation">
<t>The PCEP extensions defined in this document has been implemented
by a vendor on their product. No further information is available at
this time.</t>
</section>
</section>
<section anchor="sect-7" title="Security Considerations">
<t>The security considerations described in <xref target="RFC5440"/>,
<xref target="RFC8231"/>, and <xref target="RFC8281"/> apply to the
extensions defined in this document as well.</t> extensions defined in this document as well.</t>
<t>Two new Association Types for the ASSOCIATION object, Single-Sided
<t>Two new Association Types for the ASSOCIATION Object, Single-sided Bidirectional LSP Association and Double-Sided Bidirectional LSP
Bidirectional LSP Association and Double-sided Bidirectional LSP Association, are introduced in this document. Additional security
Association are introduced in this document. Additional security
considerations related to LSP associations due to a malicious PCEP considerations related to LSP associations due to a malicious PCEP
speaker is described in <xref target="RFC8697"/> and apply to these speaker are described in <xref target="RFC8697" format="default"/> and app ly to these
Association Types. Hence, securing the PCEP session using Transport Association Types. Hence, securing the PCEP session using Transport
Layer Security (TLS) <xref target="RFC8253"/> is RECOMMENDED.</t> Layer Security (TLS) <xref target="RFC8253" format="default"/> is <bcp14>R ECOMMENDED</bcp14>.</t>
</section> </section>
<section anchor="sect-8" numbered="true" toc="default">
<section anchor="sect-8" title="Manageability Considerations"> <name>Manageability Considerations</name>
<section anchor="sect-8.1" title="Control of Function and Policy"> <section anchor="sect-8.1" numbered="true" toc="default">
<name>Control of Function and Policy</name>
<t>The mechanisms defined in this document do not imply any control or <t>The mechanisms defined in this document do not imply any control or
policy requirements in addition to those already listed in <xref policy requirements 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 <xr
target="RFC8281"/>.</t> ef target="RFC8281" format="default"/>.</t>
</section> </section>
<section anchor="sect-8.2" numbered="true" toc="default">
<section anchor="sect-8.2" title="Information and Data Models"> <name>Information and Data Models</name>
<t><xref target="RFC7420"/> describes the PCEP MIB, there are no new <t><xref target="RFC7420" format="default"/> describes the PCEP MIB; the
MIB Objects defined for LSP associations.</t> re are no new
MIB objects defined for LSP associations.</t>
<t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang"/> <t>The PCEP YANG module <xref target="I-D.ietf-pce-pcep-yang" format="de
defines data model for LSP associations.</t> fault"/>
defines a data model for LSP associations.</t>
</section> </section>
<section anchor="sect-8.3" numbered="true" toc="default">
<section anchor="sect-8.3" title="Liveness Detection and Monitoring"> <name>Liveness Detection and Monitoring</name>
<t>The mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
liveness detection and monitoring requirements in addition to those liveness detection and monitoring requirements in addition to those
already listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, already listed in <xref target="RFC5440" format="default"/>, <xref targe
and <xref target="RFC8281"/>.</t> t="RFC8231" format="default"/>,
and <xref target="RFC8281" format="default"/>.</t>
</section> </section>
<section anchor="sect-8.4" numbered="true" toc="default">
<section anchor="sect-8.4" title="Verify Correct Operations"> <name>Verify Correct Operations</name>
<t>The mechanisms defined in this document do not imply any new <t>The mechanisms defined in this document do not imply any new
operation verification requirements in addition to those already operation verification requirements in addition to those already
listed in <xref target="RFC5440"/>, <xref target="RFC8231"/>, and listed in <xref target="RFC5440" format="default"/>, <xref target="RFC82
<xref target="RFC8281"/>.</t> 31" format="default"/>, and
<xref target="RFC8281" format="default"/>.</t>
</section> </section>
<section anchor="sect-8.5" numbered="true" toc="default">
<section anchor="sect-8.5" title="Requirements On Other Protocols"> <name>Requirements on Other Protocols</name>
<t>The mechanisms defined in this document do not add any new <t>The mechanisms defined in this document do not add any new
requirements on other protocols.</t> requirements on other protocols.</t>
</section> </section>
<section anchor="sect-8.6" numbered="true" toc="default">
<section anchor="sect-8.6" title="Impact On Network Operations"> <name>Impact on Network Operations</name>
<t>The 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 anchor="sect-9" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="sect-9" title="IANA Considerations"> <section anchor="sect-9.1" numbered="true" toc="default">
<section anchor="sect-9.1" title="Association Types"> <name>Association Types</name>
<t>This document defines two new Association Types, originally described in <t>This document defines two new Association Types
<xref target="RFC8697"/>. IANA is requested to assign the following new val <xref target="RFC8697" format="default"/>. IANA has assigned the following
ues in the new values in the
"ASSOCIATION Type Field" subregistry <xref target="RFC8697"/> within the "Pa "ASSOCIATION Type Field" subregistry <xref target="RFC8697" format="default"
th /> within the "Path
Computation Element Protocol (PCEP) Numbers" registry:</t> Computation Element Protocol (PCEP) Numbers" registry:</t>
<figure> <table anchor="assoc-types">
<artwork> <name>Additions to ASSOCIATION Type Field Subregistry</name>
Type Name Reference <thead>
TBD1 Single-sided Bidirectional LSP Association [This document] <tr>
TBD2 Double-sided Bidirectional LSP Association [This document] <th>Type</th>
</artwork> <th>Name</th>
</figure> <th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>4</td>
<td>Single-Sided Bidirectional LSP Association</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>5</td>
<td>Double-Sided Bidirectional LSP Association</td>
<td>RFC 9059</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="sect-9.2" numbered="true" toc="default">
<section anchor="sect-9.2" <name>Bidirectional LSP Association Group TLV</name>
title="Bidirectional LSP Association Group TLV">
<t>This document defines a new TLV for carrying additional information <t>This document defines a new TLV for carrying additional information
of LSPs within a Bidirectional LSP Association. IANA is about LSPs within a Bidirectional LSP Association. IANA has
requested to add the assignment of a new value in the existing "PCEP assigned the following value in the "PCEP
TLV Type Indicators" registry as follows:</t> TLV Type Indicators" subregistry within the "Path Computation Element Pr
otocol (PCEP) Numbers" registry:</t>
<figure> <table anchor="new-tlv">
<artwork> <name>Addition to PCEP TLV Type Indicators Subregistry
Value Meaning Reference </name>
TBD3 Bidirectional LSP Association Group TLV [This document] <thead>
</artwork> <tr>
</figure> <th>Value</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>54</td>
<td>Bidirectional LSP Association Group TLV</td>
<td>RFC 9059</td>
</tr>
</tbody>
</table>
<section anchor="sect-9.2.1" <section anchor="sect-9.2.1" numbered="true" toc="default">
title="Flag Field in Bidirectional LSP Association Group TLV"> <name>Flag Field in Bidirectional LSP Association Group TLV</name>
<t>This document requests that a new sub-registry, named <t>IANA has created a new subregistry, named
"Bidirectional LSP Association Group TLV Flag Field", is created "Bidirectional LSP Association Group TLV Flag Field",
within the "Path Computation Element Protocol (PCEP) Numbers" within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the Flag field in the Bidirectional LSP registry to manage the Flag field in the Bidirectional LSP
Association Group TLV. New values are to be assigned by Standards Association Group TLV. New values are assigned by Standards
Action <xref target="RFC8126"/>. Each bit should be tracked with the Action <xref target="RFC8126" format="default"/>. Each bit should be t
racked with the
following qualities:</t> following qualities:</t>
<ul spacing="normal">
<li>Bit number (count from 0 as the most significant bit)</li>
<li>Description</li>
<li>Reference</li>
</ul>
<t>The initial contents of this registry are as follows:
</t>
<t><list style="symbols"> <table anchor="flag-field">
<t>Bit number (count from 0 as the most significant bit)</t> <name>New Bidirectional LSP Association Group TLV Flag Field Subregistry</name
>
<t>Description</t> <thead>
<tr>
<t>Reference</t> <th>Bit</th>
</list></t> <th>Description</th>
<th>Reference</th>
<t>The following values are defined in this document for the Flag </tr>
field.</t> </thead>
<tbody>
<figure> <tr>
<artwork> <td>0-29</td>
Bit No. Description Reference <td>Unassigned</td>
31 R - Reverse LSP [This document] <td></td>
30 C - Co-routed Path [This document] </tr>
0-29 Unassigned <tr>
</artwork> <td>30</td>
</figure> <td>C - Co-routed Path</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>31</td>
<td>R - Reverse LSP</td>
<td>RFC 9059</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="sect-9.3" numbered="true" toc="default">
<name>PCEP Errors</name>
<t>This document defines new Error-values for Error-Type 26
(Association Error). IANA has allocated the following new Error-values
within the "PCEP-ERROR Object Error Types and Values" subregistry of
the "Path Computation Element Protocol (PCEP) Numbers" registry:</t>
<section anchor="sect-9.3" title="PCEP Errors"> <table anchor="error-value">
<t>This document defines new Error value for Error Type 26 <name>Additions to PCEP-ERROR Object Error Types and Values Subregistry</name>
(Association Error). IANA is requested to allocate new Error value <thead>
within the "PCEP-ERROR Object Error Types and Values" sub-registry of <tr>
the PCEP Numbers registry, as follows:</t> <th>Error-Type</th>
<th>Meaning</th>
<figure> <th>Error-value</th>
<artwork> <th>Reference</th>
Error Type Description Reference </tr>
26 Association Error </thead>
<tbody>
Error value: TBD4 [This document] <tr>
Bidirectional LSP Association - Group Mismatch <td rowspan="6">26</td>
<td rowspan="6">Association Error</td>
<td>14: Association group mismatch</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>15: Tunnel mismatch in the association group</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>16: Path Setup Type not supported</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>17: Bidirectional LSP direction mismatch</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>18: Bidirectional LSP co-routed mismatch</td>
<td>RFC 9059</td>
</tr>
<tr>
<td>19: Endpoint mismatch in the association group</td>
<td>RFC 9059</td>
</tr>
</tbody>
</table>
Error value: TBD5 [This document] </section>
Bidirectional LSP Association - Tunnel Mismatch </section>
</middle>
<back>
Error value: TBD6 [This document] <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
Bidirectional LSP Association - Path Setup Type <displayreference target="I-D.ietf-pce-pcep-stateful-pce-gmpls" to="STATEFUL-PCE
Not Supported -GMPLS"/>
<displayreference target="I-D.ietf-pce-sr-bidir-path" to="BIDIR-PATH"/>
Error value: TBD7 [This document] <references>
Bidirectional LSP Association - Direction Mismatch <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.3209.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.7551.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.8537.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.5654.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/bibxml/reference.R
FC.8408.xml"/>
Error value: TBD8 [This document] <!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists -->
Bidirectional LSP Association - Co-routed Mismatch
Error value: TBD9 [This document] <reference anchor='I-D.ietf-pce-pcep-yang'>
Bidirectional LSP Association - Endpoint Mismatch <front>
<title>A YANG Data Model for Path Computation Element Communications Protocol (P
CEP)</title>
</artwork> <author initials='D' surname='Dhody' fullname='Dhruv Dhody' role="editor">
</figure> <organization />
</section> </author>
</section>
</middle>
<back> <author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
<references title="Normative References"> <organization />
&RFC2119; </author>
&RFC3209; <author initials='V' surname='Beeram' fullname='Vishnu Beeram'>
<organization />
</author>
&RFC5440; <author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
<organization />
</author>
&RFC7551; <date month='February' day='22' year='2021' />;
&RFC8126; </front>;
&RFC8174; <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>
&RFC8231; <!-- [I-D.ietf-pce-pcep-stateful-pce-gmpls] IESG state I-D Exists -->;
&RFC8253; <reference anchor='I-D.ietf-pce-pcep-stateful-pce-gmpls'>
<front>
<title>Path Computation Element (PCE) Protocol Extensions for Stateful PCE Usage
in GMPLS-controlled Networks</title>
&RFC8281; <author initials='Y' surname='Lee' fullname='Young Lee' role="editor">
<organization />
</author>
&RFC8537; <author initials='H' surname='Zheng' fullname='Haomian Zheng' role="editor">
<organization />
</author>
&RFC8697; <author initials='O' surname='de Dios' fullname='Oscar de Dios'>
</references> <organization />
</author>
<references title="Informative References"> <author initials='V' surname='Lopez' fullname='Victor Lopez'>
&RFC5654; <organization />
</author>
&RFC7420; <author initials='Z' surname='Ali' fullname='Zafar Ali'>
<organization />
</author>
&RFC7942; <date month='December' day='28' year='2020' />;
&RFC8051; </front>;
&RFC8408; <seriesInfo name='Internet-Draft' value='draft-ietf-pce-pcep-stateful-pce-gmpls-
14' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-stateful
-pce-gmpls-14.txt' />
</reference>
&I-D.ietf-pce-pcep-yang; <!-- [I-D.ietf-pce-sr-bidir-path] IESG state I-D Exists -->
&I-D.ietf-pce-pcep-stateful-pce-gmpls;
&I-D.ietf-pce-sr-bidir-path;
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
.ietf-pce-sr-bidir-path.xml"/>
</references>
</references> </references>
<section anchor="acknowledgments" numbered="false" toc="default">
<section anchor="acknowledgments" numbered="no" title="Acknowledgments"> <name>Acknowledgments</name>
<t>The authors would like to thank Dhruv Dhody for various discussions <t>The authors would like to thank <contact fullname="Dhruv Dhody"/> for v
arious discussions
on association groups and inputs to this document. The authors would on association groups and inputs to this document. The authors would
also like to thank Mike Taillon, Harish Sitaraman, Al Morton, and Marina Fizgeer for also like to thank <contact fullname="Mike Taillon"/>, <contact fullname= "Harish Sitaraman"/>, <contact fullname="Al Morton"/>, and <contact fullname="Ma rina Fizgeer"/> for
reviewing this document and providing valuable comments. reviewing this document and providing valuable comments.
The authors would like to thank the following IESG members for their The authors would like to thank the following IESG members for their
review comments and suggestions: Barry Leiba, Éric Vyncke, Benjamin Kaduk, review comments and suggestions: <contact fullname="Barry Leiba"/>, <conta
Murray Kucherawy, Martin Duke, and Alvaro Retana. ct fullname="Éric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>,
<contact fullname="Murray Kucherawy"/>, <contact fullname="Martin Duke"/>,
and <contact fullname="Alvaro Retana"/>.
</t> </t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 175 change blocks. 
788 lines changed or deleted 829 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/