rfc9357.original.xml   rfc9357.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?rfc strict="yes"?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc tocdepth="4"?> std" consensus="true" docName="draft-ietf-pce-lsp-extended-flags-09" number="935
<?rfc symrefs="yes"?> 7" ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" toc
<?rfc sortrefs="yes"?> Depth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-pce-lsp-extended-flags-09" ipr="trust200902" obsoletes="" updates="" submissi
onType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRe
fs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.15.1 --> <!-- xml2rfc v2v3 conversion 3.15.1 -->
<front> <front>
<title abbrev="LSP Object Flag Extn">Label Switched Path (LSP) Object Flag E <title abbrev="LSP Object Flag Extension">Label Switched Path (LSP) Object F
xtension for Stateful PCE</title> lag Extension for Stateful PCE</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-lsp-extended-flags-0 <seriesInfo name="RFC" value="9357"/>
9"/>
<author fullname="Quan Xiong" initials="Q" surname="Xiong"> <author fullname="Quan Xiong" initials="Q" surname="Xiong">
<organization>ZTE Corporation</organization> <organization>ZTE Corporation</organization>
<address> <address>
<postal> <postal>
<street>No.6 Huashi Park Rd</street> <street>No.6 Huashi Park Rd</street>
<city>Wuhan</city> <city>Wuhan</city>
<region>Hubei</region> <region>Hubei</region>
<code>430223</code> <code>430223</code>
<country>China</country> <country>China</country>
</postal> </postal>
<phone/> <phone/>
<email>xiong.quan@zte.com.cn</email> <email>xiong.quan@zte.com.cn</email>
</address> </address>
</author> </author>
<area>Routing</area> <date year="2023" month="January"/>
<workgroup>PCE</workgroup> <area>rtg</area>
<workgroup>pce</workgroup>
<keyword>PCEP</keyword> <keyword>PCEP</keyword>
<abstract> <abstract>
<t>RFC 8231 describes a set of extensions to Path Computation Element Comm unication <t>RFC 8231 describes a set of extensions to the Path Computation Element Communication
Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched
Paths (LSPs) via PCEP. One of the extensions is the LSP object w hich includes Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes
a Flag field with a length of 12 bits. However, all bits of the Flag field have a Flag field with a length of 12 bits. However, all bits of the Flag field have
already been assigned in RFC 8231, RFC 8281, RFC 8623 and I-D.ie already been assigned.</t>
tf-pce-binding-label-sid.</t>
<t>[Note to RFC Editor - Replace I-D.ietf-pce-binding-label-sid to RFC XXX <t>This document defines a new LSP-EXTENDED-FLAG TLV for the
X, once the RFC number is assigned.]</t> LSP object for an extended Flag field.</t>
<t>This document proposes to define a new LSP-EXTENDED-FLAG TLV for the
LSP object for an extended flag field.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t><xref target="RFC5440" format="default"/> describes the Path Computatio <t><xref target="RFC5440" format="default"/> describes the Path Computatio
n Element (PCE) n Element
Communication Protocol (PCEP) which is used between a PCE and a Path Comp Communication Protocol (PCEP), which is used between a PCE and a Path Com
utation putation
Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Client (PCC) (or other PCE) to enable computation of Multi-protocol Label
Switching for Traffic Engineering (MPLS-TE) Label Switched Path (LSP). </ t> Switching for Traffic Engineering (MPLS-TE) Label Switched Paths (LSPs). </t>
<t>PCEP Extensions for the Stateful PCE Model <xref target="RFC8231" forma t="default"/> <t>PCEP Extensions for the Stateful PCE Model <xref target="RFC8231" forma t="default"/>
describes a set of extensions to PCEP to enable active control of MPLS-TE and describes a set of extensions to PCEP to enable active control of MPLS-TE and
Generalized MPLS (GMPLS) tunnels. One of the extensions is the LSP object , Generalized MPLS (GMPLS) tunnels. One of the extensions is the LSP object ,
which contains a flag field; bits in the flag field are used to indicate which contains a Flag field; bits in the Flag field are used to indicate
delegation, synchronization, removal, etc.</t> delegation, synchronization, removal, etc.</t>
<t>As defined in <xref target="RFC8231" format="default"/>, the length of <t>As defined in <xref target="RFC8231" format="default"/>, the length of the Fl
the flag field is ag field is
12 bits and the values from bit 5 to bit 11 are used for operational, adm 12 bits, and all of the bits have already been defined as shown in <xref target=
inistrative, "table0"/>. This document extends the
remove, synchronize and delegate bits respectively. The bit value 4 is as Flag field of the LSP object for other use by defining a new LSP-EXTENDED-FLA
signed in <xref target="RFC8281" format="default"/> G TLV for an extended Flag field in the LSP object (see <xref target="LSP-EXTEND
to identify the PCE-Initiated LSPs. The bits from 1 to 3 are assigned in ED-FLAG-TLV"/>).</t>
<xref target="RFC8623" format="default"/> <table anchor="table0">
for Explicit Route Object (ERO)-compression, fragmentation and Point-to-M <name>LSP Object Flag Field</name>
ultipoint (P2MP) <thead>
respectively. The bit 0 is assigned in <xref target="I-D.ietf-pce-binding <tr>
-label-sid" format="default"/> to PCE-allocation. <th>Bit</th>
All bits of the Flag field have been assigned already. This document exte <th>Description</th>
nds the <th>Reference</th>
flag field of the LSP Object for other use.</t> </tr>
<t>This document proposes to define a new LSP-EXTENDED-FLAG TLV for an ext </thead>
ended flag field in the LSP object.</t> <tbody>
<tr>
<td>0</td>
<td>PCE-allocation</td>
<td><xref target="I-D.ietf-pce-binding-label-sid" format="default"/></td>
</tr>
<tr>
<td>1</td>
<td>ERO-compression</td>
<td><xref target="RFC8623"/></td>
</tr>
<tr>
<td>2</td>
<td>Fragmentation</td>
<td><xref target="RFC8623"/></td>
</tr>
<tr>
<td>3</td>
<td>P2MP</td>
<td><xref target="RFC8623"/></td>
</tr>
<tr>
<td>4</td>
<td>Create</td>
<td><xref target="RFC8281"/></td>
</tr>
<tr>
<td>5-7</td>
<td>Operational (3 bits)</td>
<td><xref target="RFC8281"/></td>
</tr>
<tr>
<td>8</td>
<td>Administrative</td>
<td><xref target="RFC8281"/></td>
</tr>
<tr>
<td>9</td>
<td>Remove</td>
<td><xref target="RFC8281"/></td>
</tr>
<tr>
<td>10</td>
<td>SYNC</td>
<td><xref target="RFC8281"/></td>
</tr>
<tr>
<td>11</td>
<td>Delegate</td>
<td><xref target="RFC8281"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Conventions used in this document</name> <name>Conventions Used in this Document</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>The terminology is defined as <xref target="RFC5440" format="default" /> and <xref target="RFC8231" format="default"/>.</t> <t>The terminology is defined in <xref target="RFC5440" format="default" /> and <xref target="RFC8231" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format=" NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
default"/> when, RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
and only when, they appear in all capitals, as shown here.</t> "<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>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>PCEP Extension</name> <name>PCEP Extension</name>
<t>The LSP Object is defined in Section 7.3 of <xref target="RFC8231" form
at="default"/>. <t>The LSP object is defined in <xref target="RFC8231" sectionFormat="of"
This document proposes to define a new LSP-EXTENDED-FLAG TLV for an exten section="7.3"/>.
ded flag field in the LSP object.</t> This document defines a new LSP-EXTENDED-FLAG TLV for an extended Flag fi
<section numbered="true" toc="default"> eld in the LSP object.</t>
<section numbered="true" toc="default" anchor="LSP-EXTENDED-FLAG-TLV">
<name>The LSP-EXTENDED-FLAG TLV</name> <name>The LSP-EXTENDED-FLAG TLV</name>
<t>The format of the LSP-EXTENDED-FLAG TLV follows the format of <t>The format of the LSP-EXTENDED-FLAG TLV shown in <xref target="fig1"
all PCEP TLVs as defined in <xref target="RFC5440" format="default"/> and is format="default"/> follows the format of
shown in <xref target="fig1" format="default"/>. </t> all PCEP TLVs, as defined in <xref target="RFC5440" format="default"/>.</t>
<figure anchor="fig1"> <figure anchor="fig1">
<name>Figure 1: LSP-EXTENDED-FLAG TLV Format</name> <name>LSP-EXTENDED-FLAG TLV Format</name>
<artwork align="center" name="" type="" alt=""><![CDATA[ <artwork align="center" name="" type="" 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=TBD1 | Length | | Type=64 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// LSP Extended Flags // // LSP Extended Flags //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
]]></artwork>
</figure> </figure>
<t keepWithPrevious="true"/> <t keepWithPrevious="true"/>
<t>Type (16 bits): TBD1.</t> <dl newline="false" spacing="normal">
<t>Length (16 bits): indicates the length of the value portion in bytes. <dt>Type (16 bits):</dt>
It MUST be in multiples of 4 and greater than 0.</t> <dd>64</dd>
<t>LSP Extended Flags: this contains an array of units of 32-bit flags <dt>Length (16 bits):</dt>
<dd>This indicates the length of the value portion in bytes.
It <bcp14>MUST</bcp14> be in multiples of 4 and greater than 0.</dd>
<dt>LSP Extended Flags:</dt>
<dd>This contains an array of units of 32-bit flags
numbered from the most significant as bit zero, where each bit numbered from the most significant as bit zero, where each bit
represents one LSP flag (for operation, feature, or state). The represents one LSP flag (for operation, feature, or state). The
LSP Extended Flags field SHOULD use the minimal amount of space LSP Extended Flags field <bcp14>SHOULD</bcp14> use the minimal amount o f space
needed to encode the flag bits. Currently, no bits are assigned. needed to encode the flag bits. Currently, no bits are assigned.
Unassigned bits MUST be set to zero on transmission and MUST be Unassigned bits <bcp14>MUST</bcp14> be set to zero on transmission and
ignored on receipt. </t> <bcp14>MUST</bcp14> be
ignored on receipt. </dd>
</dl>
<t>As an example of usage of the LSP-EXTENDED-FLAG TLV, the E-flag <t>As an example of usage of the LSP-EXTENDED-FLAG TLV, the E-flag
is requested for entropy label configuration as proposed in <xref target= "I-D.peng-pce-entropy-label-position" format="default"/>.</t> is requested for entropy label configuration, as proposed in <xref target ="I-D.peng-pce-entropy-label-position" format="default"/>.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Processing</name> <name>Processing</name>
<t>The LSP Extended Flags field is an array of units of 32 flags, to be <t>The LSP Extended Flags field is an array of units of 32 flags that ar e
allocated starting from the most significant bit. The bits of the LSP Extende d allocated starting from the most significant bit. The bits of the LSP Extende d
Flags field will be assigned by future documents. This document does not defi ne Flags field will be assigned by future documents. This document does not defi ne
any flags. Flags that an implementation is not supporting MUST be set to any flags. Flags that an implementation is not supporting <bcp14>MUST</bcp14> be set to
zero on transmission. Implementations that do not understand any particular zero on transmission. Implementations that do not understand any particular
flag MUST ignore the flag.</t> flag <bcp14>MUST</bcp14> ignore the flag.</t>
<t>Note that PCEP peers MUST handle varying lengths of the <t>Note that PCEP peers <bcp14>MUST</bcp14> handle varying lengths of th
e
LSP-EXTENDED-FLAG TLV.</t> LSP-EXTENDED-FLAG TLV.</t>
<t>If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV <t>If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV
of a length more than it currently supports or understands, of a length more than it currently supports or understands,
it MUST ignore the bits beyond that length.</t> it <bcp14>MUST</bcp14> ignore the bits beyond that length.</t>
<t>If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of <t>If a PCEP speaker receives the LSP-EXTENDED-FLAG TLV of a length less
a length less than the one supported by the implementation, than the one supported by the implementation, it <bcp14>MUST</bcp14> act as i
it MUST treat the bits beyond the length to be unset.</t> f the bits
beyond the length were not set.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Advice for Specification of New Flags</name> <name>Advice for Specification of New Flags</name>
<t>Following the model provided in <xref target="RFC8786" format="default" /> Section 3.1, we provide <t>Following the model provided in <xref target="RFC8786" sectionFormat="o f" section="3.1"/>, we provide
the following advice for new specifications that define additional the following advice for new specifications that define additional
flags. Each such specification is expected to describe the flags. Each such specification is expected to describe the
interaction between these new flags and any existing flags. In interaction between these new flags and any existing flags. In
particular, new specifications are expected to explain how to handle particular, new specifications are expected to explain how to handle
the cases when both new and pre-existing flags are set. the cases when both new and preexisting flags are set.
They are also expected to discuss any security implications of the They are also expected to discuss any security implications of the
additional flags (if any) and their interactions with existing flags.</t> additional flags (if any) and their interactions with existing flags.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Backward Compatibility</name> <name>Backward Compatibility</name>
<t>The LSP-EXTENDED-FLAG TLV defined in this document does not introduce <t>The LSP-EXTENDED-FLAG TLV defined in this document does not introduce
any backward compatibility issues. An implementation that does not any backward compatibility issues. An implementation that does not
understand or support the LSP-EXTENDED-FLAG TLV MUST ignore understand or support the LSP-EXTENDED-FLAG TLV <bcp14>MUST</bcp14> ignore
the TLV as per <xref target="RFC5440" format="default"/>. It is expected that the TLV, as per <xref target="RFC5440" format="default"/>. Future documents t
future documents that hat
define bits in the LSP-EXTENDED-FLAG TLV will also define the error define bits in the LSP-EXTENDED-FLAG TLV are expected to also define the erro
case handling required for missing LSP-EXTENDED-FLAG TLV if it MUST r
handling required for cases in which the LSP-EXTENDED-FLAG TLV is missing whe
n it <bcp14>MUST</bcp14>
be present.</t> be present.</t>
<t>Further, any additional bits in the LSP-EXTENDED-FLAG TLV that are <t>Further, any additional bits in the LSP-EXTENDED-FLAG TLV that are
not understood by an implementation MUST be ignored. It is expected not understood by an implementation <bcp14>MUST</bcp14> be ignored.
that future documents that define bits in the LSP-EXTENDED-FLAG TLV It is expected that future documents that define bits in the LSP-EXTENDED-FLA
will take that into consideration. </t> G TLV
will take take that into consideration. </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>LSP Object</name> <name>LSP Object</name>
<section numbered="true" toc="default"> <section numbered="true" anchor="pcep64" toc="default">
<name>PCEP TLV Type Indicators</name> <name>PCEP TLV Type Indicators</name>
<t>IANA is requested to allocate the following TLV Type Indicator valu <t>IANA has allocated the following TLV Type Indicator value within
e within the "PCEP TLV Type Indicators" registry of the "Path Computation
the "PCEP TLV Type Indicators" subregistry of the "Path Computation
Element Protocol (PCEP) Numbers" registry:</t> Element Protocol (PCEP) Numbers" registry:</t>
<table anchor="table1" align="center"> <table anchor="table1" align="center">
<thead> <thead>
<tr> <tr>
<th align="left"> Value </th> <th align="left"> Value </th>
<th align="left"> Description </th> <th align="left"> Description </th>
<th align="left"> Reference </th> <th align="left"> Reference </th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">TBD1</td> <td align="left">64</td>
<td align="left">LSP-EXTENDED-FLAG</td> <td align="left">LSP-EXTENDED-FLAG</td>
<td align="left">[This document]</td> <td align="left">RFC 9357</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>LSP Extended Flags Field</name> <name>LSP Extended Flags Field</name>
<t>IANA is requested to create a new subregistry called "LSP-EXTENDED- FLAG TLV Flag Field", <t>IANA has created the "LSP-EXTENDED-FLAG TLV Flag Field" registry
within the "Path Computation Element Protocol (PCEP) Numbers" within the "Path Computation Element Protocol (PCEP) Numbers"
registry to manage the LSP Extended Flags field of the LSP-EXTENDED-FLAG TLV. New values are registry to manage the LSP Extended Flags field of the LSP-EXTENDED-FLAG TLV. New values are
assigned by Standards Action <xref target="RFC8126" format="default"/>. Each bit should be tracked assigned by Standards Action <xref target="RFC8126" format="default"/>. Each bit should be tracked
with the following qualities:</t> with the following qualities:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Bit number (counting from bit 0 as the most significant bit)</li > <li>Bit number (counting from bit 0 as the most significant bit)</li >
<li>Capability description</li> <li>Capability Description</li>
<li>Defining RFC</li> <li>Reference</li>
</ul> </ul>
<t/> <t>No values are currently defined. Bits 0-31 are initially marked
<t>No values are currently defined. Bits 0-31 should initially be mark
ed
as "Unassigned". Bits with a higher ordinal than 31 will be added to the as "Unassigned". Bits with a higher ordinal than 31 will be added to the
registry in future documents if necessary.</t> registry in future documents if necessary.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Implementation Status</name>
<t>[NOTE TO RFC EDITOR : This whole section and the reference to
<xref target="RFC7942" format="default"/> is to be removed before publication
as an RFC]</t>
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in <xref target="RFC7942
" format="default"/>.
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" format="default"/>, "this will allo
w 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>
<t>At the time of posting this version of this document, there are no
known implementations of this TLV. It is believed that this would
be implemented alongside the documents that allocate flags in the
TLV. </t>
</section>
<section numbered="true" toc="default">
<name>Management Considerations</name> <name>Management Considerations</name>
<t>Implementations receiving set LSP Extended Flags that they do not recog nize <t>Implementations receiving set LSP Extended Flags that they do not recog nize
MAY log this. That could be helpful for diagnosing backward <bcp14>MAY</bcp14> log this. That could be helpful for diagnosing backward
compatibility issues with future features that utilize those flags.</t> compatibility issues with future features that utilize those flags.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t><xref target="RFC8231" format="default"/> sets out security considerati ons for PCEP when <t><xref target="RFC8231" format="default"/> sets out security considerati ons for PCEP when
used for communication with a stateful PCE. This document does not chang e used for communication with a stateful PCE. This document does not chang e
those considerations. For LSP Object processing, see <xref target="RFC8231" format="default"/>.</t> those considerations. For LSP object processing, see <xref target="RFC8231" format="default"/>.</t>
<t>The flags for the LSP object and their associated security <t>The flags for the LSP object and their associated security
considerations are specified in <xref target="RFC8231" format="default"/>, < xref target="RFC8281" format="default"/>, <xref target="RFC8623" format="default "/>, considerations are specified in <xref target="RFC8231" format="default"/>, < xref target="RFC8281" format="default"/>, <xref target="RFC8623" format="default "/>,
and <xref target="I-D.ietf-pce-binding-label-sid" format="default"/>.</t> and <xref target="I-D.ietf-pce-binding-label-sid" format="default"/>.</t>
<t>This document provides for the future addition of flags in the LSP Obje ct. <t>This document provides for the future addition of flags in the LSP obje ct.
Any future document that specifies new flags must also discuss any Any future document that specifies new flags must also discuss any
associated security implications. No additional security issues are associated security implications. No additional security issues are
raised in this document beyond those that exist in the referenced raised in this document beyond those that exist in the referenced
documents. Note that the <xref target="RFC8231" format="default"/> recommends documents.
that the stateful PCEP extension are authenticated and encrypted Note that <xref target="RFC8231" format="default"/> recommends
using Transport Layer Security (TLS) <xref target="RFC8253" format="default"/ that the stateful PCEP extension be authenticated and encrypted
>, as per the using Transport Layer Security (TLS) <xref target="RFC8253" format="default"/
recommendations and best current practices in <xref target="RFC7525" format=" > <xref target="I-D.dhody-pce-pceps-tls13" format="default"/>, as per the
default"/>. recommendations and best current practices in <xref target="RFC9325" format="
Assuming that recommendation is followed, then the flags will be protected by default"/>.
TLS.</t> Assuming that the recommendation is followed, then the flags will be protecte
</section> d by TLS.</t>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank Loa Andersson, Adrian Farrel, Aijun Wan
g, and Gyan Mishra for their review, suggestions and comments to this document.<
/t>
</section>
<section numbered="true" toc="default">
<name>Contributors</name>
<t>The following people have substantially contributed to this document:</
t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Dhruv Dhody
Huawei Technologies
EMail: dhruv.ietf@gmail.com
Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
]]></artwork>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-pce-binding-label-sid" to="BIND-LABEL-SID"/>
<displayreference target="I-D.peng-pce-entropy-label-position" to="PCEP-ENTROPY-
LABEL"/>
<displayreference target="I-D.dhody-pce-pceps-tls13" to="PCEPS-TLS1.3"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
<front> xml"/>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5440.
le> xml"/>
<author fullname="S. Bradner" initials="S." surname="Bradner"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
<date month="March" year="1997"/> xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8231.
<t>In many standards track documents several words are used to sig xml"/>
nify the requirements in the specification. These words are often capitalized. <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.
This document defines these words as they should be interpreted in IETF documen xml"/>
ts. This document specifies an Internet Best Current Practices for the Internet
Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC5440" target="https://www.rfc-editor.org/info/rfc5
440" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml">
<front>
<title>Path Computation Element (PCE) Communication Protocol (PCEP)<
/title>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname=
"Vasseur"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname=
"Le Roux"/>
<date month="March" year="2009"/>
<abstract>
<t>This document specifies the Path Computation Element (PCE) Comm
unication Protocol (PCEP) for communications between a Path Computation Client (
PCC) and a PCE, or between two PCEs. Such interactions include path computation
requests and path computation replies as well as notifications of specific stat
es related to the use of a PCE in the context of Multiprotocol Label Switching (
MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be
flexible and extensible so as to easily allow for the addition of further messag
es and objects, should further requirements be expressed in the future. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5440"/>
<seriesInfo name="DOI" value="10.17487/RFC5440"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8231" target="https://www.rfc-editor.org/info/rfc8
231" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml">
<front>
<title>Path Computation Element Communication Protocol (PCEP) Extens
ions for Stateful PCE</title>
<author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
<author fullname="I. Minei" initials="I." surname="Minei"/>
<author fullname="J. Medved" initials="J." surname="Medved"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<date month="September" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>Although PCEP explicitly makes no assumptions regarding the inf
ormation available to the PCE, it also makes no provisions for PCE control of ti
ming and sequence of path computations within and across PCEP sessions. This doc
ument describes a set of extensions to PCEP to enable stateful control of MPLS-T
E and GMPLS Label Switched Paths (LSPs) via PCEP.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8231"/>
<seriesInfo name="DOI" value="10.17487/RFC8231"/>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<author fullname="M. Cotton" initials="M." surname="Cotton"/>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<author fullname="T. Narten" initials="T." surname="Narten"/>
<date month="June" year="2017"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in the
se fields do not have conflicting uses and to promote interoperability, their al
locations are often coordinated by a central record keeper. For IETF protocols,
that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This document
defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Consideratio
ns is clear and addresses the various issues that are likely in the operation of
a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC5088" target="https://www.rfc-editor.org/info/rfc5
088" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5088.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5088.
<front> xml"/>
<title>OSPF Protocol Extensions for Path Computation Element (PCE) D <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5089.
iscovery</title> xml"/>
<author fullname="JL. Le Roux" initials="JL." role="editor" surname= <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9325.
"Le Roux"/> xml"/>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname= <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8253.
"Vasseur"/> xml"/>
<author fullname="Y. Ikejiri" initials="Y." surname="Ikejiri"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8281.
<author fullname="R. Zhang" initials="R." surname="Zhang"/> xml"/>
<date month="January" year="2008"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8623.
<abstract> xml"/>
<t>There are various circumstances where it is highly desirable fo <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8786.
r a Path Computation Client (PCC) to be able to dynamically and automatically di xml"/>
scover a set of Path Computation Elements (PCEs), along with information that ca
n be used by the PCC for PCE selection. When the PCE is a Label Switching Route <!-- [I-D.ietf-pce-binding-label-sid] in MISSREF state as of 11/09/22-->
r (LSR) participating in the Interior Gateway Protocol (IGP), or even a server p
articipating passively in the IGP, a simple and efficient way to announce PCEs c <reference anchor="I-D.ietf-pce-binding-label-sid">
onsists of using IGP flooding. For that purpose, this document defines extensio <front>
ns to the Open Shortest Path First (OSPF) routing protocol for the advertisement <title>
of PCE Discovery information within an OSPF area or within the entire OSPF rout Carrying Binding Label/Segment Identifier (SID) in PCE-based Networks.
ing domain. [STANDARDS-TRACK]</t> </title>
</abstract> <author initials="S." surname="Sivabalan" fullname="Siva Sivabalan">
</front> <organization>Ciena Corporation</organization>
<seriesInfo name="RFC" value="5088"/> </author>
<seriesInfo name="DOI" value="10.17487/RFC5088"/> <author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
</reference> <organization>Cisco Systems, Inc.</organization>
<reference anchor="RFC5089" target="https://www.rfc-editor.org/info/rfc5 </author>
089" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5089.xml"> <author initials="J." surname="Tantsura" fullname="Jeff Tantsura">
<front> <organization>Microsoft Corporation</organization>
<title>IS-IS Protocol Extensions for Path Computation Element (PCE) </author>
Discovery</title> <author initials="S." surname="Previdi" fullname="Stefano Previdi">
<author fullname="JL. Le Roux" initials="JL." role="editor" surname= <organization>Huawei Technologies</organization>
"Le Roux"/> </author>
<author fullname="JP. Vasseur" initials="JP." role="editor" surname= <author initials="C." surname="Li" fullname="Cheng Li" role="editor">
"Vasseur"/> <organization>Huawei Technologies</organization>
<author fullname="Y. Ikejiri" initials="Y." surname="Ikejiri"/> </author>
<author fullname="R. Zhang" initials="R." surname="Zhang"/> <date month="March" day="20" year="2022"/>
<date month="January" year="2008"/> </front>
<abstract> <seriesInfo name="Internet-Draft" value="draft-ietf-pce-binding-label-sid-15"/>
<t>There are various circumstances where it is highly desirable fo <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-pce-bindin
r a Path Computation Client (PCC) to be able to dynamically and automatically di g-label-sid-15.txt"/>
scover a set of Path Computation Elements (PCEs), along with information that ca </reference>
n be used by the PCC for PCE selection. When the PCE is a Label Switching Route
r (LSR) participating in the Interior Gateway Protocol (IGP), or even a server p <!-- [I-D.peng-pce-entropy-label-position] IESG state I-D Exists -->
articipating passively in the IGP, a simple and efficient way to announce PCEs c
onsists of using IGP flooding. For that purpose, this document defines extensio <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.peng-pc
ns to the Intermediate System to Intermediate System (IS-IS) routing protocol fo e-entropy-label-position.xml"/>
r the advertisement of PCE Discovery information within an IS-IS area or within
the entire IS-IS routing domain. [STANDARDS-TRACK]</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dhody-p
</abstract> ce-pceps-tls13.xml"/>
</front>
<seriesInfo name="RFC" value="5089"/>
<seriesInfo name="DOI" value="10.17487/RFC5089"/>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
525" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="R. Holz" initials="R." surname="Holz"/>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre
"/>
<date month="May" year="2015"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are widely used to protect data exchanged over application protocol
s such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, severa
l serious attacks on TLS have emerged, including attacks on its most commonly us
ed cipher suites and their modes of operation. This document provides recommend
ations for improving the security of deployed services that use TLS and DTLS. T
he recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
</reference>
<reference anchor="RFC7942" target="https://www.rfc-editor.org/info/rfc7
942" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7942.xml">
<front>
<title>Improving Awareness of Running Code: The Implementation Statu
s Section</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="July" year="2016"/>
<abstract>
<t>This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by including an I
mplementation Status section. This will allow reviewers and working groups to as
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.</t>
<t>This process is not mandatory. Authors of Internet-Drafts are e
ncouraged to consider using the process for their documents, and working groups
are invited to think about applying the process to all of their protocol specifi
cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
ce.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="205"/>
<seriesInfo name="RFC" value="7942"/>
<seriesInfo name="DOI" value="10.17487/RFC7942"/>
</reference>
<reference anchor="RFC8253" target="https://www.rfc-editor.org/info/rfc8
253" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml">
<front>
<title>PCEPS: Usage of TLS to Provide a Secure Transport for the Pat
h Computation Element Communication Protocol (PCEP)</title>
<author fullname="D. Lopez" initials="D." surname="Lopez"/>
<author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzal
ez de Dios"/>
<author fullname="Q. Wu" initials="Q." surname="Wu"/>
<author fullname="D. Dhody" initials="D." surname="Dhody"/>
<date month="October" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) defi
nes the mechanisms for the communication between a Path Computation Client (PCC)
and a Path Computation Element (PCE), or among PCEs. This document describes PC
EPS -- the usage of Transport Layer Security (TLS) to provide a secure transport
for PCEP. The additional security mechanisms are provided by the transport prot
ocol supporting PCEP; therefore, they do not affect the flexibility and extensib
ility of PCEP.</t>
<t>This document updates RFC 5440 in regards to the PCEP initializ
ation phase procedures.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8253"/>
<seriesInfo name="DOI" value="10.17487/RFC8253"/>
</reference>
<reference anchor="RFC8281" target="https://www.rfc-editor.org/info/rfc8
281" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8281.xml">
<front>
<title>Path Computation Element Communication Protocol (PCEP) Extens
ions for PCE-Initiated LSP Setup in a Stateful PCE Model</title>
<author fullname="E. Crabbe" initials="E." surname="Crabbe"/>
<author fullname="I. Minei" initials="I." surname="Minei"/>
<author fullname="S. Sivabalan" initials="S." surname="Sivabalan"/>
<author fullname="R. Varga" initials="R." surname="Varga"/>
<date month="December" year="2017"/>
<abstract>
<t>The Path Computation Element Communication Protocol (PCEP) prov
ides mechanisms for Path Computation Elements (PCEs) to perform path computation
s in response to Path Computation Client (PCC) requests.</t>
<t>The extensions for stateful PCE provide active control of Multi
protocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP
s) via PCEP, for a model where the PCC delegates control over one or more locall
y configured LSPs to the PCE. This document describes the creation and deletion
of PCE-initiated LSPs under the stateful PCE model.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8281"/>
<seriesInfo name="DOI" value="10.17487/RFC8281"/>
</reference>
<reference anchor="RFC8623" target="https://www.rfc-editor.org/info/rfc8
623" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8623.xml">
<front>
<title>Stateful Path Computation Element (PCE) Protocol Extensions f
or Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)</title>
<author fullname="U. Palle" initials="U." surname="Palle"/>
<author fullname="D. Dhody" initials="D." surname="Dhody"/>
<author fullname="Y. Tanaka" initials="Y." surname="Tanaka"/>
<author fullname="V. Beeram" initials="V." surname="Beeram"/>
<date month="June" year="2019"/>
<abstract>
<t>The Path Computation Element (PCE) has been identified as an ap
propriate technology for the determination of the paths of point- to-multipoint
(P2MP) TE Label Switched Paths (LSPs). This document provides extensions requir
ed for the Path Computation Element Communication Protocol (PCEP) so as to enabl
e the usage of a stateful PCE capability in supporting P2MP TE LSPs.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8623"/>
<seriesInfo name="DOI" value="10.17487/RFC8623"/>
</reference>
<reference anchor="RFC8786" target="https://www.rfc-editor.org/info/rfc8
786" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8786.xml">
<front>
<title>Updated Rules for Processing Stateful PCE Request Parameters
Flags</title>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="May" year="2020"/>
<abstract>
<t>Extensions to the Path Computation Element Communication Protoc
ol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RF
C 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) objec
t. That object includes a Flags field that is a set of 32 bit flags, and RFC 828
1 defines an IANA registry for tracking assigned flags. However, RFC 8231 does n
ot explain how an implementation should set unassigned flags in transmitted mess
ages, nor how an implementation should process unassigned, unknown, or unsupport
ed flags in received messages.</t>
<t>This document updates RFC 8231 by defining the correct behavior
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8786"/>
<seriesInfo name="DOI" value="10.17487/RFC8786"/>
</reference>
<reference anchor="I-D.ietf-pce-binding-label-sid" target="https://www.i
etf.org/archive/id/draft-ietf-pce-binding-label-sid-15.txt" xml:base="https://bi
b.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-pce-binding-label-sid.xml">
<front>
<title>Carrying Binding Label/Segment Identifier (SID) in PCE-based
Networks.</title>
<author fullname="Siva Sivabalan" surname="Siva Sivabalan">
<organization>Ciena Corporation</organization>
</author>
<author fullname="Clarence Filsfils" surname="Clarence Filsfils">
<organization>Cisco Systems, Inc.</organization>
</author>
<author fullname="Jeff Tantsura" surname="Jeff Tantsura">
<organization>Microsoft Corporation</organization>
</author>
<author fullname="Stefano Previdi" surname="Stefano Previdi">
<organization>Huawei Technologies</organization>
</author>
<author fullname="Cheng Li (editor)" surname="Cheng Li (editor)">
<organization>Huawei Technologies</organization>
</author>
<date day="20" month="March" year="2022"/>
<abstract>
<t>In order to provide greater scalability, network confidentialit
y, and service independence, Segment Routing (SR) utilizes a Binding Segment Ide
ntifier (SID) (called BSID) as described in RFC 8402. It is possible to associat
e a BSID to an RSVP-TE-signaled Traffic Engineering Label Switched Path or an SR
Traffic Engineering path. The BSID can be used by an upstream node for steering
traffic into the appropriate TE path to enforce SR policies. This document spec
ifies the concept of binding value, which can be either an MPLS label or Segment
Identifier. It further specifies an extension to Path Computation Element (PCE)
communication Protocol(PCEP) for reporting the binding value by a Path Computat
ion Client (PCC) to the PCE to support PCE-based Traffic Engineering policies.</
t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-pce-binding-label-
sid-15"/>
</reference>
<reference anchor="I-D.peng-pce-entropy-label-position" target="https://
www.ietf.org/archive/id/draft-peng-pce-entropy-label-position-08.txt" xml:base="
https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.peng-pce-entropy-label-
position.xml">
<front>
<title>PCEP Extension for SR-MPLS Entropy Label Position</title>
<author fullname="Quan Xiong" surname="Quan Xiong">
<organization>ZTE Corporation</organization>
</author>
<author fullname="Shaofu Peng" surname="Shaofu Peng">
<organization>ZTE Corporation</organization>
</author>
<author fullname="Fengwei Qin" surname="Fengwei Qin">
<organization>China Mobile</organization>
</author>
<date day="29" month="August" year="2022"/>
<abstract>
<t>This document proposes a set of extensions for PCEP to configur
e the entropy label position for SR-MPLS networks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-peng-pce-entropy-label-
position-08"/>
</reference>
</references> </references>
</references> </references>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>WG Discussion</name> <name>Working Group Discussion</name>
<t> <t>
The WG discussed the idea of a fixed length (with 32 bits) for LSP- The working group discussed the idea of a fixed length (with 32 bits) fo
EXTENDED-FLAG TLV. Though 32 bits would be sufficient for quite a r the
while, the use of variable length with a multiple of 32-bits allows LSP-EXTENDED-FLAG TLV. Though 32 bits would be sufficient for quite a
while, the use of variable length with a multiple of 32 bits allows
for future extensibility where we would never run out of flags and for future extensibility where we would never run out of flags and
there would not be a need to define yet another TLV in the future. there would not be a need to define yet another TLV in the future.
Further, note that <xref target="RFC5088" format="default"/> and <xref target ="RFC5089" format="default"/> use the same approach for Further, note that <xref target="RFC5088" format="default"/> and <xref target ="RFC5089" format="default"/> use the same approach for
the PCE-CAP-FLAGS Sub-TLV and are found to be useful. the PCE-CAP-FLAGS sub-TLV and are found to be useful.
</t> </t>
</section> </section>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors would like to thank <contact fullname="Loa Andersson"/>, <c
ontact fullname="Adrian Farrel"/>, <contact fullname="Aijun Wang"/>, and <contac
t fullname="Gyan Mishra"/> for their reviews, suggestions, and comments for this
document.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>The following people have substantially contributed to this document:</
t>
<contact fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<email>dhruv.ietf@gmail.com</email>
</address>
</contact>
<contact fullname="Greg Mirsky">
<organization>Ericsson</organization>
<address>
<email>gregimirsky@gmail.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 50 change blocks. 
551 lines changed or deleted 279 lines changed or added

This html diff was produced by rfcdiff 1.48.