rfc9488xml2.original.xml   rfc9488.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> <!DOCTYPE rfc [
<?rfc toc="yes" ?> <!ENTITY nbsp "&#160;">
<?rfc symrefs="yes" ?> <!ENTITY zwsp "&#8203;">
<rfc ipr="trust200902" docName="draft-ietf-pce-local-protection-enforcement-11" <!ENTITY nbhy "&#8209;">
category="std" updates="5440"> <!ENTITY wj "&#8288;">
<front> ]>
<title abbrev="Protection Enforcement">Local Protection Enforcement in P
CEP</title>
<author fullname="Andrew Stone" initials="A." surname="Stone">
<organization>Nokia</organization>
<address>
<postal>
<street>600 March Road</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2T6</code>
<country>Canada</country>
</postal>
<email>andrew.stone@nokia.com</email>
</address>
</author>
<author fullname="Mustapha Aissaoui" initials="M." surname="Aissaoui">
<organization>Nokia</organization>
<address>
<postal>
<street>600 March Road</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 2T6</code>
<country>Canada</country>
</postal>
<email>mustapha.aissaoui@nokia.com</email>
</address>
</author>
<author fullname="Samuel Sidor" initials="S." surname="Sidor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Eurovea Central 3.</street>
<street>Pribinova 10</street>
<city>Bratislava</city>
<code>811 09</code>
<country>Slovakia</country>
</postal>
<email>ssidor@cisco.com</email>
</address>
</author>
<author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<organization>Ciena Coroporation</organization>
<address>
<postal>
<street>385 Terry Fox Drive</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 0L1</code>
<country>Canada</country>
</postal>
<email>ssivabal@ciena.com</email>
</address>
</author>
<date year="2023" month="June" day="23"/>
<abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<t>This document updates RFC5440 to clarify usage of the local prote -ietf-pce-local-protection-enforcement-11" number="9488" submissionType="IETF" c
ction desired bit signalled in the Path Computation Element Protocol (PCEP). ategory="std" consensus="true" updates="5440" obsoletes="" xml:lang="en" tocIncl
This document also introduces a new flag for signalling protecti ude="true" sortRefs="true" symRefs="true" version="3">
on strictness in PCEP.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction" toc="default">
<t>The Path Computation Element (PCE) Communication Protocol (PCEP)
<xref target="RFC5440" /> enables the communication between a Path Computation C
lient (PCC) and a PCE, or between two PCEs based on the PCE architecture <xref t
arget="RFC4655" />. </t>
<t>PCEP <xref target="RFC5440" /> utilizes flags, values and concept
s previously defined in RSVP-TE Extensions <xref target="RFC3209" /> and Fast Re
route Extensions to RSVP-TE <xref target="RFC4090" />.
One such concept in PCEP is the 'Local Protection Desired' (L fl
ag in the LSPA Object in <xref target="RFC5440" />),
which was originally defined in the SESSION-ATTRIBUTE Object in
RFC3209. In RSVP, this flag signals to downstream routers that they may use a lo
cal repair mechanism.
The headend router calculating the path does not know whether a
downstream router will or will not protect a hop during its calculation.
Therefore, a local protection desired does not require the trans
it router to satisfy protection in order to establish the RSVP signalled path.
This flag is signalled in PCEP as an attribute of the LSP via th
e LSP Attributes object. </t>
<t>PCEP Extensions for Segment Routing (<xref target="RFC8664" />) e <front>
xtends support in PCEP for Segment Routed paths. The path list is encoded with S <title abbrev="Local Protection Enforcement in PCEP">Local Protection Enforc
egment Identifiers, each of which might offer local protection. ement in the Path Computation Element Communication Protocol (PCEP)</title>
The PCE may discover the protection eligibility for a Segment Id <seriesInfo name="RFC" value="9488"/>
entifier (SID) via BGP-LS <xref target="RFC9085" /> and take the protection into <author fullname="Andrew Stone" initials="A." surname="Stone">
consideration as a path constraint. <organization>Nokia</organization>
</t> <address>
<t>It is desirable for an operator to be able to define the enforcem <postal>
ent, or strictness of the protection requirement. </t> <street>600 March Road</street>
<t>This document updates <xref target="RFC5440" /> by further descri <city>Kanata</city>
bing the behaviour with the Local Protection Desired Flag (L flag) and extends o <region>Ontario</region>
n it with the introduction of the Enforcement Flag (E flag).</t> <code>K2K 2T6</code>
<t>The document contains reference notes for Segment Routing, howeve <country>Canada</country>
r the content described is path setup type and data plane technology agnostic.</ </postal>
t> <email>andrew.stone@nokia.com</email>
</section> </address>
<section title="Requirements Language" anchor="requirements-language"> </author>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", " <author fullname="Mustapha Aissaoui" initials="M." surname="Aissaoui">
<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "< <organization>Nokia</organization>
bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", <address>
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", <postal>
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i <street>600 March Road</street>
nterpreted <city>Kanata</city>
as described in BCP 14 <xref target="RFC2119" format="default" s <region>Ontario</region>
ectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="defa <code>K2K 2T6</code>
ult" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, <country>Canada</country>
they appear in all capitals, as shown here.</t> </postal>
</section> <email>mustapha.aissaoui@nokia.com</email>
<section title="Terminology" anchor="terminology"> </address>
<t>This document uses the following terminology:</t> </author>
<t> PROTECTION MANDATORY: The Path MUST have protection eligibilit <author fullname="Samuel Sidor" initials="S." surname="Sidor">
y on all links.</t> <organization>Cisco Systems, Inc.</organization>
<t> UNPROTECTED MANDATORY: The Path MUST NOT have protection eligi <address>
bility on all links.</t> <postal>
<t> PROTECTION PREFERRED: The Path should have protection eligibil <extaddr>Eurovea Central 3</extaddr>
ity on all links but might contain links which do not have protection eligibilit <street>Pribinova 10</street>
y.</t> <city>Bratislava</city>
<t> UNPROTECTED PREFERRED: The Path should not have protection eli <code>811 09</code>
gibility on all links but might contain links which have protection eligibility. <country>Slovakia</country>
</t> </postal>
<t> PCC: Path Computation Client. Any client application request <email>ssidor@cisco.com</email>
ing a </address>
path computation to be performed by a Path Computation Element.< </author>
/t> <author fullname="Siva Sivabalan" initials="S." surname="Sivabalan">
<t> PCE: Path Computation Element. An entity (component, applica <organization>Ciena Corporation</organization>
tion, <address>
<postal>
<street>385 Terry Fox Drive</street>
<city>Kanata</city>
<region>Ontario</region>
<code>K2K 0L1</code>
<country>Canada</country>
</postal>
<email>ssivabal@ciena.com</email>
</address>
</author>
<date year="2023" month="October"/>
<area>rtg</area>
<workgroup>pce</workgroup>
<keyword>segment routing</keyword>
<keyword>adjacency sid</keyword>
<keyword>sla</keyword>
<keyword>fast reroute</keyword>
<keyword>ti-lfa</keyword>
<abstract>
<t>This document updates RFC 5440 to clarify usage of the Local Protection
Desired bit signaled in the Path Computation Element Communication Protocol (PC
EP).
This document also introduces a new flag for signaling protectio
n enforcement in PCEP.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" toc="default" numbered="true">
<name>Introduction</name>
<t>The Path Computation Element Communication Protocol (PCEP) <xref target
="RFC5440" format="default"/> enables the communication between a Path Computati
on Client (PCC) and a PCE or between two PCEs based on the PCE architecture <xre
f target="RFC4655" format="default"/>. </t>
<t>PCEP <xref target="RFC5440" format="default"/> utilizes flags,
values, and concepts previously defined in RSVP-TE Extensions <xref
target="RFC3209" format="default"/> and Fast Reroute Extensions to
RSVP-TE <xref target="RFC4090" format="default"/>. One such concept in
PCEP is the Local Protection Desired (L) flag in the LSP
Attributes (LSPA) object in <xref target="RFC5440" format="default"/>, whi
ch
was originally defined in the Session Attribute object in <xref
target="RFC3209" format="default"/>. In RSVP, this flag signals to
downstream routers that they may use a local repair mechanism. The
headend router calculating the path does not know if a downstream
router will or will not protect a hop during its calculation.
Therefore, the L flag does not require the transit
router to satisfy protection in order to establish the RSVP-signaled
path. This flag is signaled in PCEP as an attribute of the Label Switched
Path (LSP) via the
LSPA object. </t>
<t>PCEP Extensions for Segment Routing <xref target="RFC8664"
format="default"/> extends support in PCEP for Segment Routing paths. The
path list is encoded with Segment Identifiers (SIDs), each of which
might offer local protection. The PCE may discover the protection
eligibility for a SID via the Border Gateway Protocol - Link State (BGP-LS
)
<xref target="RFC9085" format="default"/> and take the protection into
consideration as a path constraint.
</t>
<t>It is desirable for an operator to be able to define the enforcement of
the protection requirement. </t>
<t>This document updates <xref target="RFC5440" format="default"/> by furt
her describing the behavior of the Local Protection Desired (L) flag and extends
on it with the introduction of the Protection Enforcement (E) flag.</t>
<t>The document contains descriptions in the context of Segment Routing; h
owever, the content described is agnostic in regard to path setup type and data
plane technology.</t>
</section>
<section anchor="requirements-language" numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section>
<section anchor="terminology" numbered="true" toc="default">
<name>Terminology</name>
<t>This document uses the following terminology:</t>
<dl newline="false" spacing="normal">
<dt>PROTECTION MANDATORY:</dt><dd>The path <bcp14>MUST</bcp14> have protec
tion eligibility on all links.</dd>
<dt>UNPROTECTED MANDATORY:</dt><dd>The path <bcp14>MUST NOT</bcp14> have p
rotection eligibility on all links.</dd>
<dt>PROTECTION PREFERRED:</dt><dd>The path should have protection eligibil
ity on all links but might contain links that do not have protection eligibility
.</dd>
<dt>UNPROTECTED PREFERRED:</dt><dd>The path should not have protection eli
gibility on all links but might contain links that have protection eligibility.<
/dd>
<dt>PCC:</dt><dd>Path Computation Client. Any client application requesti
ng a
path computation to be performed by a Path Computation Element.<
/dd>
<dt>PCE:</dt><dd>Path Computation Element. An entity (component, applicat
ion,
or network node) that is capable of computing a network path or or network node) that is capable of computing a network path or
route based on a network graph and applying computational route based on a network graph and applying computational
constraints.</t> constraints.</dd>
<t> PCEP: Path Computation Element Protocol.</t> <dt>PCEP:</dt><dd>Path Computation Element Communication Protocol</dd>
<t> LSPA: LSP Attributes Object in PCEP, defined in RFC5440</t> <dt>LSPA:</dt><dd>LSP Attributes object <xref target="RFC5440" format="def
</section> ault"/></dd>
<section title="Motivation" anchor="motivation" toc="default"> </dl>
<section title="Implementation differences" anchor="implementation-d </section>
ifferences" toc="default"> <section anchor="motivation" toc="default" numbered="true">
<t>As defined in <xref target="RFC5440" /> the mechanism to sign <name>Motivation</name>
al protection enforcement in PCEP is the previously mentioned L flag defined in <section anchor="implementation-differences" toc="default" numbered="true"
the LSPA Object. >
The name of the flag uses the term "Desired", which by defin <name>Implementation Differences</name>
ition means "strongly wished for or intended" and the use case originated from t
he RSVP. <t>As defined in <xref target="RFC5440" format="default"/>, the mechanism
For RSVP signalled paths, local protection is not within con to signal protection enforcement in PCEP is the previously mentioned L flag defi
trol of the PCE. However, <xref target="RFC5440" /> does state "When set, this m ned in the LSPA object.
eans that the computed path must include links protected with Fast Reroute as de The name of the flag uses the term "Desired", which by defin
fined in [RFC4090]." ition means "strongly wished for or intended". The use case for this flag origin
Implementations of <xref target="RFC5440" /> have either int ated in RSVP.
erpreted the L flag as PROTECTION MANDATORY or PROTECTION PREFERRED, leading to For RSVP-signaled paths, local protection is not within cont
operational differences. </t> rol of the PCE. However, <xref target="RFC5440" format="default"/> does state th
</section> at "[w]hen set, this means that the computed path must include links protected w
<section title="SLA Enforcement" anchor="sla-enforcement" toc="defau ith Fast Reroute as defined in <xref target="RFC4090" />."
lt"> Implementations that use PCEP <xref target="RFC5440" format=
<t> The boolean bit L flag is unable to distinguish between the "default"/> have interpreted the L flag as either PROTECTION MANDATORY or PROTEC
different options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION PRE TION PREFERRED, leading to operational differences. </t>
FERRED and UNPROTECTED PREFERRED. </section>
Selecting one of the options is typically dependent on the s <section anchor="sla-enforcement" toc="default" numbered="true">
ervice <name>SLA Enforcement</name>
level agreement the operator wishes to impose on the LSP. A
network <t> The L flag is a boolean bit and thus unable to distinguish between
may be providing transit to multiple service agreement defin the different
itions against options of PROTECTION MANDATORY, UNPROTECTED MANDATORY, PROTECTION
PREFERRED, and UNPROTECTED PREFERRED.
Selecting one of these options is typically dependent on the
Service
Level Agreement (SLA) the operator wishes to impose on the L
SP. A network
may be providing transit to multiple SLA definitions against
the same base topology network, whose behavior could vary, s uch as the same base topology network, whose behavior could vary, s uch as
wanting local protection to be invoked on some LSPs and not wanting wanting local protection to be invoked on some LSPs and not wanting
local protection on others. When enforcement is used, the re sulting shortest path calculation is impacted.</t> local protection on others. When enforcement is used, the re sulting shortest path calculation is impacted.</t>
<t> For example, PROTECTION MANDATORY is for use cases where an
operator may need the LSP to follow a path which has local protection provided a <t> For example, PROTECTION MANDATORY is for use cases in whi
long the full path, ensuring that ch an operator may need the LSP to follow a path that has local protection provi
if there is a failure anywhere along the path that traffic w ded along the full path, ensuring that
ill be fast re-routed at the point. </t> traffic will be fast rerouted at the point if there is a fai
<t> For example, UNPROTECTED MANDATORY is when an operator may lure anywhere along the path. </t>
intentionally prefer an LSP to not be locally protected,
<t> As another example, UNPROTECTED MANDATORY is for use case
s in which an operator may
intentionally prefer an LSP to not be locally protected
and thus would rather local failures cause the LSP to go dow n. and thus would rather local failures cause the LSP to go dow n.
An example scenario is one where an LSP is protected with An example scenario is one where an LSP is protected via a s
path protection via a secondary diverse LSP. Each LSP is econdary diverse LSP.
traffic engineered to follow specific traffic engineered cri Each LSP is traffic engineered to follow specific traffic-en
teria gineered criteria
computed by the PCE to satisfy SLA. Upon a failure, if local computed by the PCE to satisfy the SLA. Upon a failure, if l
protection ocal protection
is invoked on the active LSP traffic, the traffic may tempor arily is invoked on the active LSP traffic, the traffic may tempor arily
traverse links which violate the TE requirements and could n egatively traverse links that violate the TE requirements and could ne gatively
impact the resources being traversed (e.g., insufficient ban dwidth). impact the resources being traversed (e.g., insufficient ban dwidth).
In addition, depending on the network topological scenario, In addition, depending on the network topological scenario,
it may be not feasible for the PCE to reroute the LSP while it may not be feasible for the PCE to reroute the LSP while
respecting the TE requirements which include path diversity, respecting the TE requirements, which include path diversity
resulting in the LSP being torn down and switched to the ; this results
protected path anyways. In such scenarios its desirable for in the LSP being torn down and switched to the
the LSP to be simply torn down immediately and not re-routed protected path anyways. In such scenarios, it is desirable f
or
the LSP to be simply torn down immediately and not rerouted
through local protection, so that traffic through local protection, so that traffic
may be forwarded through an already established may be forwarded through an already-established
traffic-engineered secondary path. </t> traffic-engineered secondary path. </t>
<t> <t>
Both UNPROTECTED PREFERRED and PROTECTED PREFERRED options p Both the UNPROTECTED PREFERRED and PROTECTED PREFERRED optio
rovide a relaxation of the protection constraint. ns provide a relaxation of the protection constraint.
These options can be used when an operator does not require protection enforcement. Regardless of the option selected, the protection status of a These options can be used when an operator does not require protection enforcement. Regardless of the option selected, the protection status of a
resource does not influence whether the link must be pruned during a path calculation. Furthermore, the selection of either option indicates a priority selection to resource does not influence whether the link must be pruned during a path calculation. Furthermore, the selection of either option indicates a priority selection to the
PCE when there is an option to choose a protected or unprote cted instruction associated with a resource, ensuring consistent PCE behavior ac ross different implementations. PCE when there is an option to choose a protected or unprote cted instruction associated with a resource, ensuring consistent PCE behavior ac ross different implementations.
</t> </t>
<t>When used with Segment Routing, an adjacency may have both a <t>When used with Segment Routing, an adjacency may have both a protecte
protected SID and an unprotected SID. d SID and an unprotected SID.
If the UNPROTECTED PREFERRED option is selected, PCE chooses If the UNPROTECTED PREFERRED option is selected, the PCE cho
the unprotected SID. Alternatively, if the PROTECTED PREFERRED option is select oses the unprotected SID. Alternatively, if the PROTECTED PREFERRED option is se
ed, PCE chooses the protected SID lected, the PCE chooses the protected SID.
</t> </t>
</section> </section>
</section> </section>
<section title="Protection Enforcement Flag (E flag)" anchor="protection <section anchor="protection-enforcement-flag--e-flag-" toc="default" numbere
-enforcement-flag--e-flag-" toc="default"> d="true">
<t>Section 7.11 in Path Computation Element Protocol <xref target="R <name>Protection Enforcement Flag (E Flag)</name>
FC5440" /> describes the encoding of the Local Protection Desired (L flag). <t><xref target="RFC5440" section="7.11" sectionFormat="of"></xref> descri
A Protection Enforcement flag "E" is specified below, extending bes the encoding of the Local Protection Desired (L) flag.
the L flag.</t> The Protection Enforcement (E) flag, which extends the L flag, i
<t>[RFC Editor Note: The text below assumes the E bit remains the ea s specified below.</t>
rly allocation value 6. Please adjust if this changes and remove this note befor <table anchor="flagfieldtable" align="left">
e publication.]</t> <name>Codespace of the Flag Field (LSPA Object)</name>
<figure> <thead>
<artwork><![CDATA[Codespace of the Flag field (LSPA Object) <tr>
<th>Bit</th>
Bit Description Reference <th>Description</th>
<th>Reference</th>
7 Local Protection Desired RFC5440 </tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>Protection Enforcement</td>
<td>RFC 9488</td>
</tr>
<tr>
<td>7</td>
<td>Local Protection Desired</td>
<td>RFC 5440</td>
</tr>
</tbody>
</table>
6 Local Protection Enforcement This document]]></artwork> <t>The following shows the format of the LSPA object as defined in <xref t
</figure> arget="RFC5440" format="default"/> with the addition of the E flag defined in th
<t>The format of the LSPA Object as defined in <xref target="RFC5440 is document:</t>
" /> is:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure>
<artwork><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any | | Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any | | Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all | | Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |E|L| Reserved | | Setup Prio | Holding Prio | Flags |E|L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Optional TLVs // // Optional TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> ]]></artwork>
</figure>
<t> Flags (8 bits)</t> <dl newline="true" spacing="normal">
<t> <dt>Flags (8 bits):</dt><dd>
<list style="symbols"> <dl newline="false" spacing="normal">
<t> <dt>L (Local Protection Desired):</dt><dd>This flag is defined in <xref target="
L Flag: As defined in RFC5440" format="default"/>
<xref target="RFC5440" /> and further updated by this document. When set to 1, protection is
and further updated by this document. When set to 1, pro desired. When set to 0, protection is not desired. The enforcement of the
tection is desired. When set to 0, protection is not desired. The enforcement of protection is identified via the E flag.</dd>
the protection is identified via the E flag. <dt>E (Protection Enforcement):</dt><dd>This flag controls the strictness
</t> with which the PCE must apply the L flag. When set to 1, the value of the L
<t>E Flag (Protection Enforcement): This flag controls the s flag needs to be respected during resource selection by the PCE. When the E fla
trictness in which the PCE must apply the L flag. g
When set to 1, the value of the L flag needs to be respected is set to 0, an attempt to respect the value of the L flag is made; however,
during resource selection by the PCE. the PCE could relax or ignore the L flag when computing a path. The
When E flag is set to 0, an attempt to respect the value of statements below indicate preference when the E flag is set to 0 in
the L flag is made; however, the PCE could relax or ignore the L flag when compu combination with the L flag value.
ting a path. </dd>
The statements below indicate preference when the E flag is </dl>
set to 0 in combination with the L flag value.</t> </dd>
</list> </dl>
</t>
<t>When both the L flag and E flag are set to 1, then the PCE MUST c <t>When both the L flag and E flag are set to 1, then the PCE <bcp14>MUST<
onsider the protection eligibility as a PROTECTION MANDATORY constraint.</t> /bcp14> consider the protection eligibility as a PROTECTION MANDATORY constraint
<t>When the L flag is set to 1 and the E flag is set to 0, then the .</t>
PCE MUST consider the protection eligibility as a PROTECTION PREFERRED constrain <t>When the L flag is set to 1 and the E flag is set to 0, then the PCE <b
t.</t> cp14>MUST</bcp14> consider the protection eligibility as a PROTECTION PREFERRED
<t> When both L flag and E flag are set to 0, then the PCE SHOULD constraint.</t>
<t> When both the L flag and E flag are set to 0, then the PCE <bcp14>SHO
ULD</bcp14>
consider the protection eligibility as an UNPROTECTED PREFERRED consider the protection eligibility as an UNPROTECTED PREFERRED
constraint but MAY consider protection eligibility as an UNPROTE CTED constraint but <bcp14>MAY</bcp14> consider the protection eligib ility as an UNPROTECTED
MANDATORY constraint. An example of when the latter behavior mig ht MANDATORY constraint. An example of when the latter behavior mig ht
be chosen is if the PCE has some means (outside the scope of thi s be chosen is if the PCE has some means (outside the scope of thi s
document) to detect that it is interacting with a legacy PCC tha t expects document) to detect that it is interacting with a legacy PCC tha t expects
the legacy behavior.</t> the legacy behavior.</t>
<t>When L flag is set to 0 and E flag is set to 1, then the PCE MUST <t>When the L flag is set to 0 and the E flag is set to 1, then the PCE <b
consider the protection eligibility as an UNPROTECTED MANDATORY constraint.</t> cp14>MUST</bcp14> consider the protection eligibility as an UNPROTECTED MANDATOR
Y constraint.</t>
<t> <t>
If a PCE is unable to infer the protection status of a resource, If a PCE is unable to infer the protection status of a resource,
the PCE MAY use local policy to define protected status assumptions. the PCE <bcp14>MAY</bcp14> use local policy to define protected status assumpti
ons.
When computing a Segment Routed path, It is RECOMMENDED that a P
CE assume a Node SID is protected. It is also RECOMMENDED that a PCE assume an A
djacency SID is protected if the backup flag advertised with the Adjacency SID i
s set.
</t>
<section title="Backwards Compatibility" anchor="compatibility" toc=
"default">
<t>Considerations in the message passing between the PCC and the
PCE for the E flag bit which are not supported by the entity are outlined in th
is section, with requirements for the PCE and the PCC implementing this document
described at the end.</t>
<t>For a PCC or PCE which does not yet support this document, th
e E flag is ignored and set to zero in PCRpt and/or PCUpd as per <xref target="R
FC5440" /> for PCC-initiated or as per <xref target="RFC8281" /> for PCE-initiat
ed LSPs. It is important to note that <xref target="RFC8231" /> and <xref target
="RFC8281" /> permit the LSP Attribute Object to be included in PCUpd messages f
or PCC-initiated and PCE-initiated LSPs.
</t>
<t>
For PCC-initiated LSPs, PCUpd E flag (and L flag) is an echo
from the previous PCRpt however the bit value is ignored on the PCE from the pr
evious PCRpt, therefore the E flag value set in the PCUpd is zero.
A PCE which does not support this document sends PCUpd messa
ges with the E flag set to 0 for PCC-initated LSPs even if set to 1 in the prior
PCReq or PCRpt.
</t>
<t>
A PCC which does not support this document sends PCRpt messa
ges with the E flag set to 0 for PCE-initiated LSPs even if set to 1 in the prio
r PCInitiate or PCUpd.
</t>
<t>For a PCC which does support this document, it MAY set the E When computing a Segment Routing path, it is <bcp14>RECOMMENDED<
flag to 1 depending on local configuration. /bcp14> that a PCE assume a Node SID is protected. It is also <bcp14>RECOMMENDED
If communicating with a PCE which does not yet support this </bcp14> that a PCE assume an Adjacency SID is protected if the backup flag adve
document, the PCE follows the behaviour specified in <xref target="RFC5440" /> a rtised with the Adjacency SID is set.
nd will ignore the E flag. </t>
<section anchor="compatibility" toc="default" numbered="true">
<name>Backwards Compatibility</name>
<t>This section outlines considerations for the E flag bit in the messag
e
passing between the PCC and the PCE that are not supported by the en
tity.
The requirements for the PCE and the PCC implementing this document
are described
at the end.</t>
<t>For a PCC or PCE that does not yet support this document, the E flag
is ignored and set to 0 in PCRpt and/or PCUpd messages as per <xref target="RFC5
440" format="default"/> for PCC-initiated LSPs or as per <xref target="RFC8281"
format="default"/> for PCE-initiated LSPs. It is important to note that <xref ta
rget="RFC8231" format="default"/> and <xref target="RFC8281" format="default"/>
permit the LSPA object <xref target="RFC5440" format="default"/> to be included
in PCUpd messages for PCC-initiated and PCE-initiated LSPs.
</t>
<t>
For PCC-initiated LSPs, the E flag (and L flag) in a PCUpd message i
s an echo from the
previous PCRpt message; however, the bit value is ignored on the PCE
from the
previous PCRpt message, so the E flag value set in the PCUpd message
is 0.
A PCE that does not support this document sends PCUpd messag
es with the E flag set to 0 for PCC-initiated LSPs even if set to 1 in the prior
PCReq or PCRpt message.
</t>
<t>
A PCC that does not support this document sends PCRpt messag
es with the E flag set to 0 for PCE-initiated LSPs even if set to 1 in the prior
PCInitiate or PCUpd message.
</t>
<t>For a PCC that does support this document, the E flag <bcp14>MAY</bcp
14> be set to 1 depending on local configuration.
If communicating with a PCE that does not yet support this d
ocument, the PCE follows the behavior specified in <xref target="RFC5440" format
="default"/> and ignores the E flag.
Thus, a computed path might not respect the enforcement cons traint.</t> Thus, a computed path might not respect the enforcement cons traint.</t>
<t>For PCC-initiated LSPs, the PCC <bcp14>SHOULD</bcp14> ignore the E fl
ag value received from the PCE in a PCUpd message as it may be communicating wit
h a PCE that does not support this document.</t>
<t>For PCE-initiated LSPs, the PCC <bcp14>MAY</bcp14> process the E flag
value received from the PCE in a PCUpd message. The PCE <bcp14>SHOULD</bcp14> i
gnore the E flag value received from the PCC in a PCRpt message as it may be com
municating with a PCC
that does not support this document. </t>
</section>
</section>
<section anchor="security-considerations" toc="default" numbered="true">
<name>Security Considerations</name>
<t>This document clarifies the behavior of an existing flag and introduces
a new flag to provide further control of that existing behavior. The introducti
on of this new flag and the behavior clarification do not create any new sensiti
ve information. No additional security measure is required.</t>
<t>Securing the PCEP session using Transport Layer Security (TLS) <xref ta
rget="RFC8253" format="default"/>, as per the recommendations and best current p
ractices in <xref target="RFC9325" format="default"/>, is <bcp14>RECOMMENDED</bc
p14>.</t>
</section>
<section anchor="iana-considerations" toc="default" numbered="true">
<name>IANA Considerations</name>
<t>This document defines a new bit value in the subregistry "LSPA Object F
lag Field" in the "Path Computation Element Protocol (PCEP) Numbers" registry. I
ANA has made the following codepoint allocation.</t>
<t>For PCC-initiated LSPs, the PCC SHOULD ignore the E flag valu <table anchor="prot-enforce-iana-table" align="left">
e received from the PCE in a PCUpd message as it may be communicating with a PCE <name>Addition to LSPA Object Flag Field Registry</name>
which does not support this document.</t> <thead>
<t>For PCE-initiated LSPs, the PCC MAY process the E flag value <tr>
received from the PCE in a PCUpd message. The PCE SHOULD ignore the E flag value <th>Bit</th>
received from the PCC in a PCRpt message as it may be communicating with a PCC <th>Description</th>
which does not support this document. </t> <th>Reference</th>
</tr>
</section> </thead>
<tbody>
</section> <tr>
<td>6</td>
<section anchor="Imp" title="Implementation Status" toc="default"> <td>Protection Enforcement</td>
<t>[Note to the RFC Editor - remove this section before publication, <td>RFC 9488</td>
as well as remove the reference to RFC 7942.]</t> </tr>
<t>This section records the status of known implementations of the </tbody>
protocol defined by this specification at the time of posting of </table>
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 contributor
s.
This is not intended as, and must not be construed to be, a
catalogue of available implementations or their features. Reade
rs
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 group
s
to use this information as they see fit".</t>
<section title="Nokia Implementation" toc="default">
<t>
<list style="symbols">
<t>Organization: Nokia</t>
<t>Implementation: NSP PCE and SROS PCC.</t>
<t>Description: Implementation for calculation and conve
ying intention described in this document</t>
<t>Maturity Level: Demo</t>
<t>Coverage: Full</t>
<t>Contact: andrew.stone@nokia.com </t>
</list>
</t>
</section>
<section title="Cisco Implementation" toc="default">
<t>
<list style="symbols">
<t>Organization: Cisco Systems, Inc.</t>
<t>Implementation: IOS-XR PCE and PCC.</t>
<t>Description: Implementation for calculation and conve
ying intention described in this document</t>
<t>Maturity Level: Demo</t>
<t>Coverage: Full</t>
<t>Contact: ssidor@cisco.com </t>
</list>
</t>
</section>
</section>
<section title="Security Considerations" anchor="security-considerations
" toc="default">
<t>This document clarifies the behaviour of an existing flag and int
roduces a new flag to provide further control of that existing behaviour. The in
troduction of this new flag and behaviour clarification does not create any new
sensitive information. No additional security measure is required.</t>
<t>Securing the PCEP session using Transport Layer Security (TLS) <x
ref target="RFC8253" />, as per the recommendations and best current practices i
n <xref target="RFC9325" /> is RECOMMENDED.</t>
</section>
<section title="IANA Considerations" anchor="iana-considerations" toc="d
efault">
<t>[RFC Editor Note: The text below assumes the E bit remains th
e early allocation value 6. Please adjust if this changes and remove this note b
efore publication.]</t>
<t>This document defines a new bit value in the sub-registry "LS
PA Object Flag Field" in the "Path Computation Element Protocol (PCEP) Numbers"
registry. IANA has made the following codepoint allocation.</t>
<figure>
<artwork>
<![CDATA[
Bit Name Reference
6 Protection Enforcement This document]]>
</artwork>
</figure>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml" ?>
<?rfc include="reference.RFC.8174.xml" ?>
<?rfc include="reference.RFC.5440.xml" ?>
<?rfc include="reference.RFC.3209.xml" ?>
<?rfc include="reference.RFC.4090.xml" ?>
<?rfc include="reference.RFC.8253.xml" ?>
<?rfc include="reference.RFC.8231.xml" ?>
<?rfc include="reference.RFC.8281.xml" ?>
<?rfc include="reference.RFC.9325.xml" ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4655.xml" ?>
<?rfc include="reference.RFC.7942.xml" ?>
<?rfc include="reference.RFC.8664.xml" ?>
<?rfc include="reference.RFC.9085.xml" ?>
</references>
<section title="Acknowledgements" anchor="Acknowledgements" numbered="fa </section>
lse" toc="default"> </middle>
<t>Thanks to Dhruv Dhody, Mike Koldychev, and John Scudder for revie <back>
wing and providing very valuable feedback and discussions on this document.</t>
<t>Thanks to Julien Meuric for shepherding this document. </t>
</section>
</back> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
209.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
281.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
325.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
655.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
664.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
085.xml"/>
</references>
</references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Dhruv Dhody"/>, <contact fullname="Mike Ko
ldychev"/>, and <contact fullname="John Scudder"/> for reviewing and providing v
ery valuable feedback and discussions on this document.</t>
<t>Thanks to <contact fullname="Julien Meuric"/> for shepherding this docu
ment. </t>
</section>
</back>
</rfc> </rfc>
 End of changes. 21 change blocks. 
420 lines changed or deleted 441 lines changed or added

This html diff was produced by rfcdiff 1.48.