rfc8786xml2.original.xml   rfc8786.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-stateful
<!ENTITY RFC4657 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC -flags-01" number="8786" ipr="trust200902" updates="8231" obsoletes="" submissio
.4657.xml"> nType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" toc
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC Depth="3" symRefs="true" sortRefs="true" version="3">
.5440.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8231 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8231.xml">
<!ENTITY RFC8281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8281.xml">
]>
<rfc category="std" docName="draft-ietf-pce-stateful-flags-01" ipr="trust200902" updates="8231">
<front> <front>
<title abbrev="Stateful PCEP Flags">Updated Rules for Processing Stateful PC E Request Parameters Flags</title> <title abbrev="Stateful PCEP Flags">Updated Rules for Processing Stateful PC E Request Parameters Flags</title>
<seriesInfo name="RFC" value="8786"/>
<author fullname="Adrian Farrel" initials="A." surname="Farrel"> <author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<date month="May" year="2020"/>
<date month="" year="2020"/> <area>Routing</area>
<workgroup>PCE</workgroup>
<area>Routing Area</area>
<workgroup>PCE Working Group</workgroup>
<keyword>PCEP</keyword> <keyword>PCEP</keyword>
<keyword>Path Computation Element</keyword> <keyword>Path Computation Element</keyword>
<keyword>Stateful PCE</keyword> <keyword>Stateful PCE</keyword>
<keyword>Flags</keyword> <keyword>Flags</keyword>
<abstract> <abstract>
<t>Extensions to the Path Computation Element Communication Protocol (PCEP <t>Extensions to the Path Computation Element Communication Protocol
) to support (PCEP) to support stateful Path Computation Elements (PCEs) are defined
stateful Path Computation Elements (PCEs) are defined in RFC 8231. One in RFC 8231. One of the extensions is the Stateful PCE Request
of the extensions Parameters (SRP) object. That object includes a Flags field that is a
is the Stateful PCE Request Parameters (SRP) object. That object inclu set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking
des a Flags field assigned flags. However, RFC 8231 does not explain how an
that is a set of 32 bit flags, and RFC 8281 defines an IANA registry fo implementation should set unassigned flags in transmitted messages, nor
r tracking assigned how an implementation should process unassigned, unknown, or unsupported
flags. However, RFC 8231 does not explain how an implementation should flags in received messages.</t>
set unassigned
flags in transmitted messages, nor how an implementation should process
unassigned, unknown,
or unsupported flags in received messages.</t>
<t>This document updates RFC 8231 by defining the correct behaviors.</t> <t>This document updates RFC 8231 by defining the correct behaviors.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<name>Introduction</name>
<t><xref target="RFC5440" /> describes the Path Computation Element Commu <t><xref target="RFC5440" format="default"/> describes the Path
nication Protocol (PCEP). Computation Element Communication Protocol (PCEP). PCEP defines the
PCEP defines the communication between a Path Computation Client (PCC) communication between a Path Computation Client (PCC) and a Path
and a Path Computation Computation Element (PCE), or between PCEs, enabling computation of
Element (PCE), or between PCEs, enabling computation of Multiprotocol Multiprotocol Label Switching (MPLS) for Traffic Engineering Label
Label Switching (MPLS) Switched Path (TE LSP) characteristics.</t>
for Traffic Engineering Label Switched Path (TE LSP) characteristics.< <t><xref target="RFC8231" format="default"/> specifies a set of
/t> extensions to PCEP to enable stateful control of LSPs within and across
PCEP sessions in compliance with <xref target="RFC4657"
<t><xref target="RFC8231" /> specifies a set of extensions to PCEP to ena format="default"/>. It includes mechanisms to effect Label Switched
ble stateful control of Path (LSP) State Synchronization between PCCs and PCEs, delegation of
LSPs within and across PCEP sessions in compliance with <xref target=" control over LSPs to PCEs, and PCE control of timing and sequence of
RFC4657" />. It includes path computations within and across PCEP sessions.</t>
mechanisms to effect Label Switched Path (LSP) State Synchronization b <t>One of the extensions defined in <xref target="RFC8231"
etween PCCs and PCEs, format="default"/> is the Stateful PCE Request Parameters (SRP) object.
delegation of control over LSPs to PCEs, and PCE control of timing and That object includes a Flags field that is a set of 32 bit flags, and
sequence of path RFC 8281 defines an IANA registry for tracking assigned
computations within and across PCEP sessions.</t> flags. However, RFC 8231 does not explain how an
implementation should set unassigned flags in transmitted messages, nor
<t>One of the extensions defined in <xref target="RFC8231" /> is the Stat how an implementation should process unassigned or unknown flags in
eful PCE Request Parameters received messages.</t>
(SRP) object. That object includes a Flags field that is a set of 32 <t>Furthermore, <xref target="RFC8231"/> gives no
bit flags, and RFC 8281 guidance to the authors of future specifications about how to describe
defines an IANA registry for tracking assigned flags. However, RFC 82 the interaction between flags that have already been defined and flags
31 does not explain how an being defined in the new specifications.</t>
implementation should set unassigned flags in transmitted messages, no
r how an implementation
should process unassigned or unknown flags in received messages.</t>
<t>Furthermore, <xref target="RFC8231" /> gives no guidance to the author
s of future specifications
about how to describe the interaction between flags that have already
been defined and flags
being defined in the new specifications.</t>
<t>This document updates RFC 8231 by defining the correct behaviors.</t> <t>This document updates RFC 8231 by defining the correct behaviors.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP 1 "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
4 "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
<xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
, <xref target="RFC8174"/> when, and only when, they appear in all capitals,
they appear in all capitals, as shown here.</t> as shown here.
</t>
</section> </section>
<section anchor="update" numbered="true" toc="default">
<name>Updated Procedures</name>
<section anchor="advice" numbered="true" toc="default">
<name>Advice for Specification of New Flags</name>
<section anchor="update" title="Updated Procedures"> <t><xref target="RFC8231" sectionFormat="of" section="7"/> introduces
changes to existing PCEP objects and defines new PCEP objects and TLVs
<section anchor="advice" title="Advice for Specification of New Flags"> in support of stateful PCE functionality. That text does not advise
future specifications on how to describe the interaction between flags
<t>Section 7 of <xref target="RFC8231" /> introduces changes to existing that may be defined.</t>
PCEP objects
and the definition of new PCEP objects and TLVs in support of statefu
l PCE functionality.
That text does not advise future specifications how to describe the i
nteraction
between flags that may be defined.</t>
<t>The text in Section 7 is updated to read as follows: <t>The text in <xref target="RFC8231" sectionFormat="of" section="7"/>
<list style="empty"> is updated to read as follows:
<t>The PCEP objects defined in this document are compliant with th </t>
e PCEP
object format defined in <xref target="RFC5440" />. The P and
I flags of the PCEP
objects defined in the current document MUST be set to 0 on
transmission and SHOULD be ignored on receipt since they are
exclusively related to path computation requests.</t>
<t>The sections that follow define PCEP objects and TLVs that cont
ain flags
fields, and some flag values are defined. Future specification
s may define
further flags, and each new specification that defines addition
al flags is
expected to describe the interaction between these new flags an
d any existing
flags. In particular, new specifications are expected to expla
in how to
handle the cases when both new and pre-existing flags are set.<
/t>
</list></t>
<ul empty="true" spacing="normal">
<li>The PCEP objects defined in this document are compliant with the
PCEP object format defined in <xref target="RFC5440"
format="default"/>. The P and I flags of the PCEP objects defined
in the current document <bcp14>MUST</bcp14> be set to 0 on
transmission and <bcp14>SHOULD</bcp14> be ignored on receipt since
they are exclusively related to path computation requests.</li>
<li>The sections that follow define PCEP objects and TLVs that
contain Flags fields, and some flag values are defined. Future
specifications may define further flags, and each new specification
that defines additional flags is expected to describe the
interaction between these new flags and any existing flags. In
particular, new specifications are expected to explain how to handle
the cases when both new and pre-existing flags are set.</li>
</ul>
</section> </section>
<section anchor="SRPflags" numbered="true" toc="default">
<section anchor="SRPflags" title="Flags Field of the SRP Object"> <name>Flags Field of the SRP Object</name>
<t><xref target="RFC8231" sectionFormat="of" section="7.2"/> defines the
<t>Section 7.2 of <xref target="RFC8231" /> defines the PCEP SRP object. PCEP SRP object. It describes
It describes the Flags field as:
the flags field as: </t>
<list style="empty"> <ul empty="true" spacing="normal">
<t>Flags (32 bits): None defined yet.</t> <li>Flags (32 bits): None defined yet.</li>
</list></t> </ul>
<t>This document updates that text as follows: <t>This document updates that text as follows:
<list style="empty"> </t>
<t>Flags (32 bits): This document does not define any flags. Unas <ul empty="true" spacing="normal">
signed flags <li>Flags (32 bits): This document does not define any flags. Unassig
MUST be set to zero on transmission and MUST be ignored on rece ned flags
ipt. <bcp14>MUST</bcp14> be set to zero on transmission and <bcp14>M
Implementations that do not understand any particular flag MUST UST</bcp14> be ignored on receipt.
ignore the Implementations that do not understand any particular flag <bcp
flag.</t> 14>MUST</bcp14> ignore the
</list></t> flag.</li>
</ul>
</section> </section>
</section>
<section anchor="Backward" title="Compatibility Considerations">
<t>While one of the main objectives of the changes made by this document
is to enable backward
compatibility, there remains an issue of compatibility between existin
g implementations of
RFC 8231 and implementations that are consistent with this document.</
t>
<t>It should be noted that common behavior for flags fields is as describ
ed by the updated text
presented in <xref target="update" />. Thus, many implementations, la
cking guidance from RFC 8231,
will still have implemented a consistent and future-proof approach. H
owever, for completeness
it is worth noting how behaviors might interact between implementation
s.</t>
<t>SRP objects generated by an implementation of this document will set a
ll unknown flag bits to
zero and will therefore cause no issues to an older implementation eve
n if it inspects those
bits. Similarly, an implementation of this document will not inspect
any unknown flag bits and
will therefore be unaffected by older implementations no matter how th
ey set the flags.</t>
<t>There will remain an issue with compatibility between implementations
of RFC 8231 that might
set any of the unassigned flags, and current (such as <xref target="RF
C8281" />) and future
(such as <xref target="I-D.ietf-pce-lsp-control-request" />) specifica
tions that assign specific
meanings to flags if set. That problem cannot be fixed in old impleme
ntations by any amount of
documentation, and can only be handled for future specifications by ob
soleting the Flags field
and using a new technique. Fortunately, however, most implementations
will have been constructed
to set unused flags to zero which is consistent with the behavior desc
ribed in this document and
so the risk of bad interactions is sufficiently small that there is no
need to obsolete the
existing Flags field.</t>
</section> </section>
<section anchor="Backward" numbered="true" toc="default">
<name>Compatibility Considerations</name>
<t>While one of the main objectives of the changes made by this document
is to enable backward compatibility, there remains an issue of
compatibility between existing implementations of RFC 8231 and
implementations that are consistent with this document.</t>
<t>It should be noted that common behavior for Flags fields is as
described by the updated text presented in <xref target="update"
format="default"/>. Thus, many implementations, lacking guidance from
RFC 8231, will still have implemented a consistent and future-proof
approach. However, for completeness, it is worth noting how behaviors
might interact between implementations.</t>
<t>SRP objects generated by an implementation of this document will set
all unknown flag bits to zero and will therefore cause no issues to an
older implementation even if it inspects those bits. Similarly, an
implementation of this document will not inspect any unknown flag bits
and will therefore be unaffected by older implementations no matter how
they set the flags.</t>
<section anchor="Imps" title="Implementation Status"> <t>There will remain an issue with compatibility between implementations
and how they set the flags. An implementation of RFC 8231 might set any
<t>[NOTE TO RFC EDITOR: Please remove this section before publication as of the unassigned flags, but an implementation of a future or current
an RFC.]</t> specification (such as <xref target="RFC8281" format="default"/> or
<xref target="RFC8741" format="default"/>) assigns specific meanings to
<t>While this document describes changes to <xref target="RFC8231" /> tha a flag if set. That problem cannot be fixed in old implementations by
t are important for any amount of documentation and can only be handled for future
implementation, and while the document gives advice to implementations specifications by obsoleting the Flags field and using a new technique.
, there is nothing Fortunately, however, most implementations will have been constructed to
specific in this document to implement.</t> set unused flags to zero, which is consistent with the behavior
described in this document, and so the risk of bad interactions is
<t>A private and unscientific poll of implementers of RFC 8231 conducted sufficiently small that there is no need to obsolete the existing Flags
by the author suggests field.</t>
that existing implementations already abide by the modification set ou
t in this document.</t>
</section> </section>
<section anchor="Management" title="Management Considerations"> <section anchor="Management" numbered="true" toc="default">
<name>Management Considerations</name>
<t>Implementations receiving set SRP flags that they do not recognize MAY <t>Implementations receiving set SRP flags that they do not recognize <bcp
log this. That could 14>MAY</bcp14> log this. That could
be helpful for diagnosing backward compatibility issues with future fe atures that utilize those be helpful for diagnosing backward compatibility issues with future fe atures that utilize those
flags.</t> flags.</t>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t><xref target="RFC8231" /> sets out security considerations for PCEP whe <t><xref target="RFC8231" format="default"/> sets out security considerati
n used for communication ons for PCEP when used for communication
with a stateful PCE. This document does not change those consideration s.</t> with a stateful PCE. This document does not change those consideration s.</t>
<t>However, by defining the expected behavior of implementations, this
<t>However, by defining the expected behavior of implementations, this doc document may improve the stability of networks and thus reduce the
ument may improve the attack surface. That is, by reminding implementations to ignore unset
stability of networks and thus reduce the attack surface. That is, by bits, it is less possible to attack them by randomly tweaking bits.
reminding implementations Furthermore, by reminding implementations to leave undefined bits unset,
to ignore unset bits, it is less possible to attack them by randomly tw the network is future-proofed against new definitions of previously
eaking bits. Furthermore, undefined bits.</t>
by reminding implementations to leave undefined bits unset, the network
is future-proofed against
new definitions of previously undefined bits.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA maintains a registry called the "Path Computation Element Protocol
(PCEP) Numbers" registry
with a subregistry called " SRP Object Flag Field". IANA is requested t
o update the Reference in
that subregistry to include a reference to this document in addition to
[RFC8281].</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>Thanks to the authors of <xref target="I-D.ietf-pce-lsp-control-request <t>IANA maintains a registry called the "Path Computation Element
" /> for exposing the Protocol (PCEP) Numbers" registry with a subregistry called "SRP Object
need for this work. Thanks to Dhruv Dhody and Julien Meuric for discus Flag Field". IANA has updated the reference for that
sing the solution. subregistry to list this document in addition to
Additional thanks to Hariharan Ananthakrishnan for his Shepherd&apos;s <xref target="RFC8281"/>.</t>
review. Thanks to
Benjamin Kaduk and Alvaro Retana for helpful comments during IESG revie
w.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.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.8281.xml"/>
</references>
<references>
<name>Informative References</name>
<references title="Normative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC2119; FC.8741.xml"/>
&RFC8174;
&RFC8231;
&RFC8281;
</references>
<references title="Informative References"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.I-D.ietf-pce-lsp-control-request"?> FC.4657.xml"/>
&RFC4657; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
&RFC5440; FC.5440.xml"/>
</references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to the authors of <xref target="RFC8741" format="default"/>
for exposing the need for this work. Thanks to <contact fullname="Dhruv
Dhody"/> and <contact fullname="Julien Meuric"/> for discussing the
solution. Additional thanks to <contact fullname="Hariharan
Ananthakrishnan"/> for his Shepherd's review. Thanks to <contact
fullname="Benjamin Kaduk"/> and <contact fullname="Alvaro Retana"/> for
helpful comments during IESG review.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 32 change blocks. 
265 lines changed or deleted 191 lines changed or added

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