rfc9168xml2.original.xml   rfc9168.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?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 [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY nbsp "&#160;">
.2119.xml"> <!ENTITY zwsp "&#8203;">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC <!ENTITY nbhy "&#8209;">
.4364.xml"> <!ENTITY wj "&#8288;">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4655.xml">
<!ENTITY RFC4657 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4657.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4760.xml">
<!ENTITY RFC5088 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5088.xml">
<!ENTITY RFC5089 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5089.xml">
<!ENTITY RFC5440 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5440.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5511.xml">
<!ENTITY RFC5886 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5886.xml">
<!ENTITY RFC6123 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6123.xml">
<!ENTITY RFC6952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6952.xml">
<!ENTITY RFC7399 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7399.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7942.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.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 RFC8232 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8232.xml">
<!ENTITY RFC8253 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8253.xml">
<!ENTITY RFC8281 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8281.xml">
<!ENTITY RFC8283 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8283.xml">
<!ENTITY RFC8664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8664.xml">
]> ]>
<rfc category="std" docName="draft-ietf-pce-pcep-flowspec-12" ipr="trust200902"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-pce-pcep-flo
wspec-12" number="9168" ipr="trust200902" obsoletes="" updates="" submissionType
<front> ="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth
<title abbrev="PCEP-FlowSpec">PCEP Extension for Flow Specification</title> ="4" symRefs="true" sortRefs="true" version="3">
<author surname="Dhody" initials="D." fullname="Dhruv Dhody">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<city>Bangalore, Karnataka</city>
<code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author surname="Farrel" initials="A." fullname="Adrian Farrel">
<organization>Old Dog Consulting</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author surname="Li" initials="Z." fullname="Zhenbin Li"> <front>
<organization>Huawei Technologies</organization> <title abbrev="PCEP Flow Spec">Path Computation Element Communication Protoc
<address> ol (PCEP) Extension for Flow Specification</title>
<postal> <seriesInfo name="RFC" value="9168"/>
<street>Huawei Bld., No.156 Beiqing Rd.</street> <author surname="Dhody" initials="D." fullname="Dhruv Dhody">
<city>Beijing</city> <organization>Huawei Technologies</organization>
<code>100095</code> <address>
<country>China</country> <postal>
</postal> <street>Divyashree Techno Park, Whitefield</street>
<email>lizhenbin@huawei.com</email> <city>Bangalore</city>
</address> <region>Karnataka</region>
</author> <code>560066</code>
<country>India</country>
</postal>
<email>dhruv.ietf@gmail.com</email>
</address>
</author>
<author surname="Farrel" initials="A." fullname="Adrian Farrel">
<organization>Old Dog Consulting</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author surname="Li" initials="Z." fullname="Zhenbin Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bldg., No. 156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<date year="2022" month="January" />
<date /> <keyword>PCE</keyword>
<keyword>FlowSpec</keyword>
<keyword>Flow Spec</keyword>
<abstract> <abstract>
<t>The Path Computation Element (PCE) is a functional component capable of sele <t>The Path Computation Element (PCE) is a functional component capable of
cting selecting
paths through a traffic engineering network. These paths may be supplied paths through a traffic engineering (TE) network. These paths may be suppli
in response to requests for computation, or may be unsolicited requests ed
in response to requests for computation or may be unsolicited requests
issued by the PCE to network elements. Both approaches use the PCE Communic ation issued by the PCE to network elements. Both approaches use the PCE Communic ation
Protocol (PCEP) to convey the details of the computed path.</t> Protocol (PCEP) to convey the details of the computed path.</t>
<t>Traffic flows may be categorized and described using "Flow Specificatio
<t>Traffic flows may be categorized and described using "Flow Specifications". ns". RFC 8955 defines the Flow Specification and describes how Flow Specificati
RFC on
XXXX defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Fl
Components are used to describe traffic flows. RFC XXXX also defines how Fl ow
ow
Specifications may be distributed in BGP to allow specific traffic flows to be Specifications may be distributed in BGP to allow specific traffic flows to be
associated with routes.</t> associated with routes.</t>
<t>This document specifies a set of extensions to PCEP to support dissemin
<t>This document specifies a set of extensions to PCEP to support dissemination ation of
of
Flow Specifications. This allows a PCE to indicate what traffic should be p laced Flow Specifications. This allows a PCE to indicate what traffic should be p laced
on each path that it is aware of.</t> on each path that it is aware of.</t>
<t>The extensions defined in this document include the creation, update, a
nd withdrawal of Flow
Specifications via PCEP and can be applied to tunnels initiated by the PCE o
r to tunnels where
control is delegated to the PCE by the Path Computation Client (PCC).
Furthermore, a PCC requesting a new path can include
Flow Specifications in the request to indicate the purpose of the tunnel a
llowing the PCE to factor this into the path computation.</t>
<t>The extensions defined in this document include the creation, update, and wi </abstract>
thdrawal of Flow </front>
Specifications via PCEP, and can be applied to tunnels initiated by the PCE <middle>
or to tunnels where <section anchor="Intro" numbered="true" toc="default">
control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a <name>Introduction</name>
new path can include <t><xref target="RFC4655" format="default"/> defines the Path Computation
Flow Specifications in the request to indicate the purpose of the tunnel all Element (PCE), a functional component
owing the PCE to factor
this into the path computation.</t>
<t>RFC Editor Note: Please replace XXXX in the Abstract with the RFC number ass
igned
to draft-ietf-idr-rfc5575bis when it is published. Please remove this note.
</t>
</abstract>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t><xref target="RFC4655"/> defines the Path Computation Element (PCE), a funct
ional component
capable of computing paths for use in traffic engineering networks. PCE was originally capable of computing paths for use in traffic engineering networks. PCE was originally
conceived for use in Multiprotocol Label Switching (MPLS) for Traffic Engine ering (TE) networks conceived for use in Multiprotocol Label Switching (MPLS) for traffic engine ering (TE) networks
to derive the routes of Label Switched Paths (LSPs). However, the scope of PCE was quickly to derive the routes of Label Switched Paths (LSPs). However, the scope of PCE was quickly
extended to make it applicable to Generalized MPLS (GMPLS)-controlled networ ks, and more recent work extended to make it applicable to networks controlled by Generalized MPLS (G MPLS), and more recent work
has brought other traffic engineering technologies and planning applications into scope (for has brought other traffic engineering technologies and planning applications into scope (for
example, Segment Routing (SR) <xref target="RFC8664" />).</t> example, Segment Routing (SR) <xref target="RFC8664" format="default"/>).</t
>
<t><xref target="RFC5440"/> describes the Path Computation Element Communicatio <t><xref target="RFC5440" format="default"/> describes the PCE
n Protocol (PCEP). Communication Protocol (PCEP).
PCEP defines the communication between a Path Computation Client (PCC) and a PCE, or between PCEP defines the communication between a Path Computation Client (PCC) and a PCE, or between
PCE and PCE, enabling computation of path for MPLS-TE LSPs.</t> PCE and PCE, enabling computation of the path for MPLS-TE LSPs.</t>
<t>Stateful PCE <xref target="RFC8231" format="default"/> specifies a set
<t>Stateful PCE <xref target="RFC8231"/> specifies a set of extensions to PCEP of extensions to PCEP to enable control of
to enable control of
TE-LSPs by a PCE that retains state about the LSPs provisioned in the networ k (a stateful PCE). TE-LSPs by a PCE that retains state about the LSPs provisioned in the networ k (a stateful PCE).
<xref target="RFC8281"/> describes the setup, maintenance, and teardown of L SPs initiated by a <xref target="RFC8281" format="default"/> describes the setup, maintenance, and teardown of LSPs initiated by a
stateful PCE without the need for local configuration on the PCC, thus allow ing for a dynamic stateful PCE without the need for local configuration on the PCC, thus allow ing for a dynamic
network that is centrally controlled. <xref target="RFC8283"/> introduces t he architecture for PCE network that is centrally controlled. <xref target="RFC8283" format="defaul t"/> introduces the architecture for PCE
as a central controller and describes how PCE can be viewed as a component t hat performs computation as a central controller and describes how PCE can be viewed as a component t hat performs computation
to place &apos;flows&apos; within the network and decide how these flows are routed.</t> to place "flows" within the network and decide how these flows are routed.</ t>
<t>The description of traffic flows by the combination of multiple Flow Specifi cation Components and <t>The description of traffic flows by the combination of multiple Flow Sp ecification components and
their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in their dissemination as traffic flow specifications (Flow Specifications) is described for BGP in
<xref target="I-D.ietf-idr-rfc5575bis" />. In BGP, a Flow Specification is comprised of traffic <xref target="RFC8955" format="default"/>. In BGP, a Flow Specification is comprised of traffic
filtering rules and is associated with actions to perform on the packets tha t match the Flow filtering rules and is associated with actions to perform on the packets tha t match the Flow
Specification. The BGP routers that receive a Flow Specification can classi fy received packets Specification. The BGP routers that receive a Flow Specification can classi fy received packets
according to the traffic filtering rules and can direct packets based on the associated actions.</t> according to the traffic filtering rules and can direct packets based on the associated actions.</t>
<t>When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) us
<t>When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) using P ing PCEP, it is important
CEP, it is important
that the head end of the tunnels understands what traffic to place on each t unnel. The data flows that the head end of the tunnels understands what traffic to place on each t unnel. The data flows
intended for a tunnel can be described using Flow Specification Components. intended for a tunnel can be described using Flow Specification components.
When PCEP is in When PCEP is in
use for tunnel initiation it makes sense for that same protocol to be used t use for tunnel initiation, it makes sense for that same protocol to be used
o distribute the Flow to distribute the Flow
Specification Components that describe what data is to flow on those tunnels Specification components that describe what data is to flow on those tunnels
.</t> .</t>
<t>This document specifies a set of extensions to PCEP to support dissemin
<t>This document specifies a set of extensions to PCEP to support dissemination ation of Flow Specification
of Flow Specification components. We term the description of a traffic flow using Flow Specificat
Components. We term the description of a traffic flow using Flow Specificat ion components as a
ion Components as a
"Flow Specification". This term is conceptually the same as the term used i n "Flow Specification". This term is conceptually the same as the term used i n
<xref target="I-D.ietf-idr-rfc5575bis" />, however, no mechanism is provided to distribute an action <xref target="RFC8955" format="default"/>; however, no mechanism is provided to distribute an action
associated with the Flow Specification because there is only one action that is applicable in the associated with the Flow Specification because there is only one action that is applicable in the
PCEP context (that is, directing the matching traffic to the identified LSP) .</t> PCEP context (that is, directing the matching traffic to the identified LSP) .</t>
<t>The extensions defined in this document include the creation, update, a
<t>The extensions defined in this document include the creation, update, and wi nd withdrawal of Flow
thdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE o
Specifications via PCEP, and can be applied to tunnels initiated by the PCE r to tunnels where
or to tunnels where
control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include control is delegated to the PCE by the PCC. Furthermore, a PCC requesting a new path can include
Flow Specifications in the request to indicate the purpose of the tunnel all owing the PCE to factor Flow Specifications in the request to indicate the purpose of the tunnel all owing the PCE to factor
this into the path computation.</t> this into the path computation.</t>
<t>Flow Specifications are carried in TLVs within a new object called the
<t>Flow Specifications are carried in TLVs within a new object called the FLOWS FLOWSPEC object defined
PEC object defined
in this document. The flow filtering rules indicated by the Flow Specificat ions are mainly in this document. The flow filtering rules indicated by the Flow Specificat ions are mainly
defined by BGP Flow Specifications.</t> defined by BGP Flow Specifications.</t>
<t>Note that PCEP-installed Flow Specifications are intended to be install
<t>Note that PCEP-installed Flow Specifications are intended to be installed on ed only at the head end of
ly at the head-end of
the LSP to which they direct traffic. It is acceptable (and potentially des irable) that other the LSP to which they direct traffic. It is acceptable (and potentially des irable) that other
routers in the network have Flow Specifications installed that match the sam e traffic, but direct routers in the network have Flow Specifications installed that match the sam e traffic but direct
it onto different routes or to different LSPs. Those other Flow Specificati ons may be installed it onto different routes or to different LSPs. Those other Flow Specificati ons may be installed
using the PCEP extensions defined in this document, may be distributed using using the PCEP extensions defined in this document, distributed using BGP pe
BGP per r
<xref target="I-D.ietf-idr-rfc5575bis" />, or may be configured using manual <xref target="RFC8955" format="default"/>, or configured using manual operat
operations. Since ions. Since
this document is about PCEP-installed Flow Specifications, those other Flow Specifications at this document is about PCEP-installed Flow Specifications, those other Flow Specifications at
other routers are out of scope. In this context, however, it is worth notin g that changes to the other routers are out of scope. In this context, however, it is worth notin g that changes to the
wider routing system (such as the distribution and installation of BGP Flow Specifications, or wider routing system (such as the distribution and installation of BGP Flow Specifications, or
fluctuations in the IGP link state database) might mean that traffic matchin g the PCEP Flow Specification fluctuations in the IGP link state database) might mean that traffic matchin g the PCEP Flow Specification
never reaches the head end of the LSP at which the PCEP Flow Specification h as been installed. This may never reaches the head end of the LSP at which the PCEP Flow Specification h as been installed. This may
or may not be desirable according to the operator&apos;s traffic engineering or may not be desirable according to the operator's traffic engineering and
and routing policies, and is routing policies and is
particularly applicable at LSPs that do not have their head ends at the ingr particularly applicable at LSPs that do not have their head ends at the ingr
ess-edge of the network, but ess edge of the network, but
it is not an effect that this document seeks to address.</t> it is not an effect that this document seeks to address.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Terminology</name>
<section title="Terminology"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>
<t>This document uses the following terms defined in <xref target="RFC5440"/>: SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
PCC, PCE, PCEP Peer.</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY<
/bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted
<t>The following term from <xref target="I-D.ietf-idr-rfc5575bis"/> is used fre as described in BCP 14 <xref target="RFC2119" format="default"/> <xref targe
quently throughout this t="RFC8174" format="default"/> when, and only when,
they appear in all capitals, as shown here.</t>
<t>This document uses the following terms defined in <xref target="RFC5440
" format="default"/>: PCC, PCE, and PCEP Peer.</t>
<t>The following term from <xref target="RFC8955" format="default"/> is us
ed frequently throughout this
document: document:
<list style="empty"> </t>
<t>A Flow Specification is an n-tuple consisting of several matching crit eria that can be <blockquote>A Flow Specification is an n-tuple consisting of several mat ching criteria that can be
applied to IP traffic. A given IP packet is said to match the defined Flow Specification applied to IP traffic. A given IP packet is said to match the defined Flow Specification
if it matches all the specified criteria.</t> if it matches all the specified criteria.</blockquote>
</list></t>
<t><xref target="I-D.ietf-idr-rfc5575bis"/> also states that "A given Flow Spec <t><xref target="RFC8955" format="default"/> also states that "[a] given F
ification may be low Specification may be
associated with a set of attributes," and that, "...attributes can be used t associated with a set of attributes" and that "...attributes can be used to
o encode a set of encode a set of
predetermined actions." However, in the context of this document, no action is explicitly predetermined actions." However, in the context of this document, no action is explicitly
specified associated with the Flow Specification since the action "forward a specified as associated with the Flow Specification since the action of forw
ll matching traffic arding all matching traffic
onto the associated path" is implicit.</t> onto the associated path is implicit.</t>
<t>How an implementation decides to filter traffic that matches a Flow Spe
<t>How an implementation decides how to filter traffic that matches a Flow Spec cification does not form
ification does not form
part of this specification, but a flag is provided to indicate whether the s ender of a PCEP part of this specification, but a flag is provided to indicate whether the s ender of a PCEP
message that includes a Flow Specification intends it to be installed as a L message that includes a Flow Specification intends it to be installed as a L
ongest Prefix ongest Prefix Match (LPM) route or as a Flow Specification policy.</t>
Match route or as a Flow Specification policy.</t> <t>This document uses the terms "stateful PCE" and "active PCE" as advocat
ed in <xref target="RFC7399" format="default"/>.</t>
<t>This document uses the terms "stateful PCE" and "active PCE" as advocated in </section>
<xref target="RFC7399" />.</t> <section numbered="true" toc="default">
<name>Procedures for PCE Use of Flow Specifications</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD" <section numbered="true" toc="default">
, "SHOULD NOT", <name>Context for PCE Use of Flow Specifications</name>
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are <t>In the PCE architecture, there are five steps in the setup and use of
to be interpreted LSPs:
as described in BCP 14 <xref target="RFC2119" /> <xref target="RFC8174" /> w </t>
hen, and only when, <ol spacing="normal" type="1"><li>Decide which LSPs to set up. The deci
they appear in all capitals, as shown here.</t> sion may be made by a user, by a PCC, or by the PCE.
There can be a number of triggers for this, including user interventi
</section> on and dynamic response
to changes in traffic demands.</li>
<section title="Procedures for PCE Use of Flow Specifications"> <li>Decide what properties to assign to an LSP. This can include band
width reservations, priorities,
<section title="Context for PCE Use of Flow Specifications"> and the Differentiated Services Code Point (DSCP) (i.e., MPLS Traffic
Class field). This function is also determined by user configuration
<t>In the PCE architecture there are five steps in the setup and use of LSPs: or in response to predicted or observed traffic demands.</li>
<list style="numbers"> <li>Decide what traffic to put on the LSP. This is effectively determ
<t>Decide which LSPs to set up. The decision may be made by a user, by ining which traffic flows to
a PCC, or by the PCE. assign to which LSPs; practically, this is closely linked to the firs
There can be a number of triggers for this including user interventio t two decisions listed
n and dynamic response above.</li>
to changes in traffic demands.</t> <li>Cause the LSP to be set up and modified to have the right characte
<t>Decide what properties to assign to an LSP. This can include bandwid ristics. This will usually
th reservations, priorities,
and DSCP (i.e., MPLS Traffic Class field). This function is also det
ermined by user configuration
or in response to predicted or observed traffic demands.</t>
<t>Decide what traffic to put on the LSP. This is effectively determini
ng which traffic flows to
assign to which LSPs, and practically, this is closely linked to the
first two decisions listed
above.</t>
<t>Cause the LSP to be set up and modified to have the right characteris
tics. This will usually
involve the PCE advising or instructing the PCC at the head end of th e LSP, and the PCC will involve the PCE advising or instructing the PCC at the head end of th e LSP, and the PCC will
then signal the LSP across the network.</t> then signal the LSP across the network.</li>
<t>Tell the head end of the LSP what traffic to put on the LSP. This ma <li>Tell the head end of the LSP what traffic to put on the LSP. This
y happen after or at the may happen after or at the
same time as the LSP is set up. This step is the subject of this doc same time as the LSP is set up. This step is the subject of this doc
ument.</t> ument.</li>
</list></t> </ol>
</section>
</section> <section numbered="true" toc="default">
<name>Elements of the Procedure</name>
<section title="Elements of Procedure"> <t>There are three elements in the procedure:
<t>There are three elements of procedure:
<list style="symbols">
<t>A PCE and a PCC must be able to indicate whether or not they support
the use of Flow
Specifications.</t>
<t>A PCE or PCC must be able to include Flow Specifications in PCEP mes </t>
sages with clear <ol spacing="normal">
<li>A PCE and a PCC must be able to indicate whether or not they suppo
rt the use of Flow
Specifications.</li>
<li>A PCE or PCC must be able to include Flow Specifications in PCEP
messages with a clear
understanding of the applicability of those Flow Specifications in e ach case. This includes understanding of the applicability of those Flow Specifications in e ach case. This includes
whether the use of such information is mandatory, constrained, or op whether the use of such information is mandatory, constrained, or op
tional, and how tional and how
overlapping Flow Specifications will be resolved.</t> overlapping Flow Specifications will be resolved.</li>
<li>Flow Specification information/state must be synchronized between
<t>Flow Specification information/state must be synchronized between PC PCEP peers so that,
EP peers so that,
on recovery, the peers have the same understanding of which Flow Spe cifications apply on recovery, the peers have the same understanding of which Flow Spe cifications apply
just as is required in the case of stateful PCE and LSP delegation ( just as is required in the case of stateful PCE and LSP delegation (
see Section 5.6 of see <xref section="5.6" target="RFC8231" sectionFormat="of"/>).</li>
<xref target="RFC8231" />).</t> </ol>
</list></t> <t>The following subsections describe these points.</t>
<section numbered="true" toc="default">
<t>The following subsections describe these points.</t> <name>Capability Advertisement</name>
<t>As with most PCEP capability advertisements, the ability to support
<section title="Capability Advertisement"> Flow Specifications can be
indicated in the PCEP Open message or in IGP PCE capability advertisemen
<t>As with most PCEP capability advertisements, the ability to support Flow ts.</t>
Specifications can be <section anchor="open" numbered="true" toc="default">
indicated in the PCEP OPEN message or in IGP PCE capability advertisemen <name>PCEP Open Message</name>
ts.</t>
<section title="PCEP OPEN Message" anchor="open">
<t>During PCEP session establishment, a PCC or PCE that supports the proc
edures described in
this document announces this fact by including the "PCE FlowSpec Capab
ility" TLV (described in
<xref target="cap"/>) in the OPEN Object carried in the PCEP Open mess
age.</t>
<t>The presence of the PCE FlowSpec Capability TLV in the OPEN Object in <t>During PCEP session establishment, a PCC or PCE that supports the
a PCE&apos;s OPEN message procedures described in
this document announces this fact by including the PCE FlowSpec Capabi
lity TLV (described in
<xref target="cap" format="default"/>) in the OPEN object carried in t
he PCEP Open message.</t>
<t>The presence of the PCE FlowSpec Capability TLV in the OPEN objec
t in a PCE's Open message
indicates that the PCE can distribute FlowSpecs to PCCs and can receiv e FlowSpecs in messages indicates that the PCE can distribute FlowSpecs to PCCs and can receiv e FlowSpecs in messages
from PCCs.</t> from PCCs.</t>
<t>The presence of the PCE FlowSpec Capability TLV in the OPEN objec
<t>The presence of the PCE FlowSpec Capability TLV in the OPEN Object in t in a PCC's Open message
a PCC&apos;s OPEN message
indicates that the PCC supports the FlowSpec functionality described i n this document.</t> indicates that the PCC supports the FlowSpec functionality described i n this document.</t>
<t>If either one of a pair of PCEP peers does not include the PCE Fl
<t>If either one of a pair of PCEP peers does not include the PCE FlowSpe owSpec Capability TLV in the
c Capability TLV in the OPEN object in its Open message, then the other peer <bcp14>MUST NOT</
OPEN Object in its OPEN message, then the other peer MUST NOT include bcp14> include a FLOWSPEC object in any
a FLOWSPEC object in any
PCEP message sent to the peer. If a FLOWSPEC object is received when support has not been indicated, PCEP message sent to the peer. If a FLOWSPEC object is received when support has not been indicated,
the receiver will respond with a PCErr message reporting the objects c ontaining the FlowSpec as described the receiver will respond with a PCErr message reporting the objects c ontaining the FlowSpec as described
in <xref target="RFC5440" />: that is, it will use &apos;Unknown Objec in <xref target="RFC5440" format="default"/>: that is, it will use "Un
t&apos; if it does not support this known Object" if it does not support this
specification, and &apos;Not supported object&apos; if it supports thi specification and "Not supported object" if it supports this specifica
s specification but has not chosen tion but has not chosen
to support FLOWSPEC objects on this PCEP session.</t> to support FLOWSPEC objects on this PCEP session.</t>
</section>
</section> <section numbered="true" toc="default">
<name>IGP PCE Capabilities Advertisement</name>
<section title="IGP PCE Capabilities Advertisement"> <t>The ability to advertise support for PCEP and PCE features in IGP
advertisements is provided
<t>The ability to advertise support for PCEP and PCE features in IGP adve for OSPF in <xref target="RFC5088" format="default"/> and for IS-IS in
rtisements is provided <xref target="RFC5089" format="default"/>. The mechanism
for OSPF in <xref target="RFC5088" /> and for IS-IS in <xref target="R uses the PCE Discovery TLV, which has a PCE-CAP-FLAGS sub-TLV containi
FC5089" />. The mechanism ng bit flags, each of which
uses the PCE Discovery TLV which has a PCE-CAP-FLAGS sub-TLV containin
g bit-flags each of which
indicates support for a different feature.</t> indicates support for a different feature.</t>
<t>This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSp
<t>This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec Ca ec Capable flag (bit number 16).
pable flag (bit number TBD1).
Setting the bit indicates that an advertising PCE supports the procedu res defined in this document.</t> Setting the bit indicates that an advertising PCE supports the procedu res defined in this document.</t>
<t>Note that while PCE FlowSpec capability may be advertised during
<t>Note that while PCE FlowSpec Capability may be advertised during disco discovery, PCEP speakers that wish to
very, PCEP speakers that wish to use Flow Specification in PCEP <bcp14>MUST</bcp14> negotiate PCE FlowS
use Flow Specification in PCEP MUST negotiate PCE FlowSpec Capability pec capability during PCEP session setup, as
during PCEP session setup, as specified in <xref target="open" format="default"/>. A PCC <bcp14>MAY
specified in <xref target="open" />. A PCC MAY initiate PCE FlowSpec </bcp14> initiate PCE FlowSpec capability negotiation at PCEP
Capability negotiation at PCEP
session setup even if it did not receive any IGP PCE capability advert isement, and a PCEP peer that session setup even if it did not receive any IGP PCE capability advert isement, and a PCEP peer that
advertised support for FlowSpec in the IGP is not obliged to support t hese procedures on any given advertised support for FlowSpec in the IGP is not obliged to support t hese procedures on any given
PCEP session.</t> PCEP session.</t>
</section>
</section> </section>
<section numbered="true" toc="default">
</section> <name>Dissemination Procedures</name>
<t>This section describes the procedures to support Flow Specification
<section title="Dissemination Procedures"> s in PCEP messages.</t>
<t>The primary purpose of distributing Flow Specification information
<t>This section describes the procedures to support Flow Specifications in is to allow a PCE to indicate to
PCEP messages.</t>
<t>The primary purpose of distributing Flow Specification information is to
allow a PCE to indicate to
a PCC what traffic it should place on a path (such as an LSP or an SR pa th). This means that the a PCC what traffic it should place on a path (such as an LSP or an SR pa th). This means that the
Flow Specification may be included in: Flow Specification may be included in:
<list style="symbols"> </t>
<ul spacing="normal">
<t>PCInitiate messages so that an active PCE can indicate the traffic <li>PCInitiate messages so that an active PCE can indicate the traff
to place on a path at the time ic to place on a path at the time
that the PCE instantiates the path.</t> that the PCE instantiates the path.</li>
<li>PCUpd messages so that an active PCE can indicate or change the
<t>PCUpd messages so that an active PCE can indicate or change the tr traffic to place on a path
affic to place on a path that has already been set up.</li>
that has already been set up.</t> <li>PCRpt messages so that a PCC can report the traffic that the PCC
will place on the path.</li>
<t>PCRpt messages so that a PCC can report the traffic that the PCC w <li>PCReq messages so that a PCC can indicate what traffic it plans
ill place on the path.</t> to place on a path when it
requests that the PCE perform a computation in case that informati
<t>PCReq messages so that a PCC can indicate what traffic it plans to on aids the PCE in its work.</li>
place on a path at the time it <li>PCRep messages so that a PCE that has been asked to compute a pa
requests the PCE to perform a computation in case that information th can suggest which traffic
aids the PCE in its work.</t> could be placed on a path that a PCC may be about to set up.</li>
<li>PCErr messages so that issues related to paths and the traffic t
<t>PCRep messages so that a PCE that has been asked to compute a path hey carry can be reported to the
can suggest which traffic PCE by the PCC and problems with other PCEP messages that carry Fl
could be placed on a path that a PCC may be about to set up.</t> ow Specifications can
be reported.</li>
<t>PCErr messages so that issues related to paths and the traffic the </ul>
y carry can be reported to the <t>To carry Flow Specifications in PCEP messages, this document define
PCE by the PCC, and so that problems with other PCEP messages that s a new PCEP object called the
carry Flow Specifications can "PCEP FLOWSPEC object". The object is <bcp14>OPTIONAL</bcp14> in the me
be reported.</t> ssages described above and <bcp14>MAY</bcp14> appear more
</list></t>
<t>To carry Flow Specifications in PCEP messages, this document defines a n
ew PCEP object called the
PCEP FLOWSPEC object. The object is OPTIONAL in the messages described
above and MAY appear more
than once in each message.</t> than once in each message.</t>
<t>To describe a traffic flow, the PCEP FLOWSPEC object carries a Flow Filter TLV.</t>
<t>To describe a traffic flow, the PCEP FLOWSPEC object carries one of the <t>The inclusion of multiple PCEP FLOWSPEC objects allows multiple tra
following combinations of ffic flows to be placed on a single
TLVs:
<list style="symbols">
<t>zero or one Flow Filter TLV</t>
<t>one L2 Flow Filter TLV</t>
<t>both a Flow Filter TLV and an L2 Flow Filter TLV</t>
</list></t>
<t>The inclusion of multiple PCEP FLOWSPEC objects allows multiple traffic
flows to be placed on a single
path.</t> path.</t>
<t>Once a PCE and PCC have established that they can both support the
<t>Once a PCE and PCC have established that they can both support the use o use of Flow Specifications in PCEP
f Flow Specifications in PCEP
messages, such information may be exchanged at any time for new or exist ing paths.</t> messages, such information may be exchanged at any time for new or exist ing paths.</t>
<t>The application and prioritization of Flow Specifications are descr
<t>The application and prioritization of Flow Specifications is described i ibed in <xref target="priorities" format="default"/>.</t>
n <xref target="priorities" />.</t> <t>As per <xref target="RFC8231" format="default"/>, any attributes of
the path received from a PCE are subject to the PCC's
<t>As per <xref target="RFC8231" />, any attributes of the path received fr local policy. This holds true for the Flow Specifications as well.</t>
om a PCE are subject to PCC&apos;s </section>
local policy. This holds good for the Flow Specifications as well.</t> <section numbered="true" toc="default">
<name>Flow Specification Synchronization</name>
</section> <t>The Flow Specifications are carried along with the LSP state inform
ation as per <xref target="RFC8231" format="default"/>,
<section title="Flow Specification Synchronization">
<t>The Flow Specifications are carried along with the LSP State information
as per <xref target="RFC8231" />
making the Flow Specifications part of the LSP database (LSP-DB). Thus, the synchronization of the Flow making the Flow Specifications part of the LSP database (LSP-DB). Thus, the synchronization of the Flow
Specification information is done as part of LSP-DB synchronization. Th is may be achieved using normal Specification information is done as part of LSP-DB synchronization. Th is may be achieved using normal
state synchronization procedures as described in <xref target="RFC8231" state synchronization procedures as described in <xref target="RFC8231"
/> or enhanced state synchronization format="default"/> or enhanced state synchronization
procedures as defined in <xref target="RFC8232" />.</t> procedures as defined in <xref target="RFC8232" format="default"/>.</t>
<t>The approach selected will be implementation and deployment specifi
<t>The approach selected will be implementation and deployment specific and c and will depend on issues such as
will depend on issues such as
how the databases are constructed and what level of synchronization supp ort is needed.</t> how the databases are constructed and what level of synchronization supp ort is needed.</t>
</section>
</section> </section>
</section>
</section> <section anchor="cap" numbered="true" toc="default">
<name>PCE FlowSpec Capability TLV</name>
</section> <t>The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be carried
in the OPEN object
<section title="PCE FlowSpec Capability TLV" anchor="cap"> <xref target="RFC5440" format="default"/> to exchange the PCE FlowSpec capab
ilities of the PCEP speakers.</t>
<t>The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be carried in th <t>The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of all
e OPEN Object PCEP TLVs
<xref target="RFC5440"/> to exchange PCE FlowSpec capabilities of the PCEP s as defined in <xref target="RFC5440" format="default"/> and is shown in <xre
peakers.</t> f target="capfig" format="default"/>.</t>
<figure anchor="capfig">
<t>The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of all PCEP <name>PCE-FLOWSPEC-CAPABILITY TLV Format</name>
TLVs <artwork name="" type="" align="left" alt=""><![CDATA[
as defined in <xref target="RFC5440" /> and is shown in <xref target="capfig
" />.</t>
<figure title="PCE-FLOWSPEC-CAPABILITY TLV format" anchor="capfig">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=TBD2 | Length=2 | | Type=51 | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value=0 | Padding | | Value=0 | Padding |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The type of the PCE-FLOWSPEC-CAPABILITY TLV is 51, and it has a fixed l
ength of 2 octets.
<t>The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a fixed lengt The Value field <bcp14>MUST</bcp14> be set to 0 and <bcp14>MUST</bcp14> be i
h of 2 octets. gnored on receipt. The two bytes of padding
The Value field MUST be set to 0 and MUST be ignored on receipt. The two by <bcp14>MUST</bcp14> be set to zero and ignored on receipt.</t>
tes of padding <t>The inclusion of this TLV in an OPEN object indicates that the sender c
MUST be set to zero and ignored on receipt.</t> an perform FlowSpec handling
<t>The inclusion of this TLV in an OPEN object indicates that the sender can pe
rform FlowSpec handling
as defined in this document.</t> as defined in this document.</t>
</section>
<section numbered="true" toc="default">
<name>PCEP FLOWSPEC Object</name>
<t>The PCEP FLOWSPEC object defined in this document is compliant with the
PCEP object format
defined in <xref target="RFC5440" format="default"/>.
</section> It is <bcp14>OPTIONAL</bcp14> in the PCReq, PCRep, PCErr, PCInitiate,
PCRpt, and PCUpd messages and <bcp14>MAY</bcp14> be present zero, one, or mo
<section title="PCEP FLOWSPEC Object"> re times. Each instance of the
<t>The PCEP FLOWSPEC object defined in this document is compliant with the PCEP
object format
defined in <xref target="RFC5440"/>. It is OPTIONAL in the PCReq, PCRep, PC
Err, PCInitiate,
PCRpt, and PCUpd messages and MAY be present zero, one, or more times. Each
instance of the
object specifies a separate traffic flow.</t> object specifies a separate traffic flow.</t>
<t>The PCEP FLOWSPEC object <bcp14>MAY</bcp14> carry a FlowSpec filter rul
<t>The PCEP FLOWSPEC object carries a FlowSpec filter rule encoded in a TLV (a e encoded in a Flow Filter TLV as defined in <xref target="tlv" format="default"
Flow Filter TLV, />.</t>
a single L2 Flow Filter TLV, or both) as defined in <xref target="tlv" />).< <t>The FLOWSPEC Object-Class is 43 (to be assigned by IANA).</t>
/t> <t>The FLOWSPEC Object-Type is 1.</t>
<t>The format of the body of the PCEP FLOWSPEC object is shown in <xref ta
<t>The FLOWSPEC Object-Class is TBD3 (to be assigned by IANA).</t> rget="FlowSpecFig" format="default"/>.</t>
<figure anchor="FlowSpecFig">
<t>The FLOWSPEC Object-Type is 1.</t> <name>PCEP FLOWSPEC Object Body Format</name>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>The format of the body of the PCEP FLOWSPEC object is shown in <xref target=
"FlowSpecFig" /></t>
<figure title="PCEP FLOWSPEC Object Body Format" anchor="FlowSpecFig">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FS-ID | | FS-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFI | Reserved | Flags |L|R| | AFI | Reserved | Flags |L|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// TLVs // // TLVs //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure>
<t>FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec information. A <dl>
PCE <dt>FS-ID (32 bits):</dt>
<dd> A PCEP-specific identifier for the FlowSpec information. A PCE
or PCC creates an FS-ID for each FlowSpec that it originates, and the value is or PCC creates an FS-ID for each FlowSpec that it originates, and the value is
unique within the scope of that PCE or PCC and is constant for the lifetime of a unique within the scope of that PCE or PCC and is constant for the lifetime of a
PCEP session. All subsequent PCEP messages can identify the FlowSpec using the PCEP session. All subsequent PCEP messages can identify the FlowSpec using the
FS-ID. The values 0 and 0xFFFFFFFF are reserved and MUST NOT be used. Note FS-ID. The values 0 and 0xFFFFFFFF are reserved and <bcp14>MUST NOT</bcp14>
that <xref target="I-D.gont-numeric-ids-sec-considerations" /> gives advice be used. Note
on that <xref target="I-D.gont-numeric-ids-sec-considerations" format="default"
assigning transient numeric identifiers such as the FS-ID so as to minimise /> gives advice on
security risks.</t> assigning transient numeric identifiers such as the FS-ID so as to minimize
security risks.</dd>
<t>AFI (16-bits): Address Family Identifier as used in BGP <xref target="RFC476 <dt>AFI (16 bits):</dt>
0"/> <dd> Address Family Identifier as used in BGP <xref target="RFC4760" format=
(AFI=1 for IPv4 or VPNv4, AFI=2 for IPv6 and VPNv6 as per as per "default"/>
<xref target="I-D.ietf-idr-flow-spec-v6"/>).</t> (AFI=1 for IPv4 or VPNv4, AFI=2 for IPv6 and VPNv6 as per
<xref target="RFC8956" format="default"/>).</dd>
<t>Reserved (8-bits): MUST be set to zero on transmission and ignored on receip
t.</t>
<t>Flags (8-bits): Two flags are currently assigned -
<list style="empty"> <dt>Reserved (8 bits):</dt>
<dd> <bcp14>MUST</bcp14> be set to zero on transmission and ignored on re
ceipt.</dd>
<dt>Flags (8 bits):</dt>
<dd><t>Two flags are currently assigned: </t>
<t>R bit: The Remove bit is set when a PCEP FLOWSPEC object is included in <dl>
a PCEP <dt>R bit:</dt>
<dd>The Remove bit is set when a PCEP FLOWSPEC object is included in a PC
EP
message to indicate removal of the Flow Specification from the associate d tunnel. message to indicate removal of the Flow Specification from the associate d tunnel.
If the bit is clear, the Flow Specification is being added or modified.< If the bit is clear, the Flow Specification is being added or modified.<
/t> /dd>
<dt>L bit:</dt>
<t>L bit: The Longest Prefix Match (LPM) bit is set to indicate that the Fl <dd>The Longest Prefix Match (LPM) bit is set to indicate that the Flow
ow Specification is to be installed as a route subject to LPM
Specification is to be installed as a route subject to longest prefix ma
tch
forwarding. If the bit is clear, the Flow Specification described by th e forwarding. If the bit is clear, the Flow Specification described by th e
Flow Filter TLV (see <xref target="tlv" />) is to be installed as a Flow Flow Filter TLV (see <xref target="tlv" format="default"/>) is to be ins talled as a Flow
Specification. If the bit is set, only Flow Specifications that describ e Specification. If the bit is set, only Flow Specifications that describ e
IPv4 or IPv6 destinations are meaningful in the Flow Filter TLV and othe IPv4 or IPv6 destinations are meaningful in the Flow Filter TLV, and oth
rs are ignored. If the L ers are ignored.
If the L
is set and the receiver does not support the use of Flow Specifications that is set and the receiver does not support the use of Flow Specifications that
are present in the Flow Filter TLV for the installation of a route subje ct to are present in the Flow Filter TLV for the installation of a route subje ct to
longest prefix match forwarding, then the PCEP peer MUST respond with a LPM forwarding, then the PCEP peer <bcp14>MUST</bcp14> respond with a PC
PCErr Err
message with error-type TBD8 (FlowSpec Error) and error-value 5 (Unsuppo message with Error-Type 30 (FlowSpec Error) and Error-value 5 (Unsupport
rted ed
LPM Route).</t> LPM Route).</dd>
</dl>
<t>Unassigned bits MUST be set to zero on transmission and ignored on recei </dd>
pt.</t> </dl>
</list></t>
<t>If the PCEP speaker receives a message with R bit set in the FLOWSPEC object
and the Flow Specification
identified with a FS-ID does not exist, it MUST generate a PCErr with Error-
type TBD8 (FlowSpec Error),
error-value 4 (Unknown FlowSpec). </t>
<t>If the PCEP speaker does not understand or support the AFI in the FLOWSPEC m <t>Unassigned bits <bcp14>MUST</bcp14> be set to zero on transmission an
essage, the PCEP peer d ignored on receipt.
MUST respond with a PCErr message with error-type TBD8 (FlowSpec Error), err </t>
or-value 2 <t>If the PCEP speaker receives a message with the R bit set in the FLOWSP
EC object and the Flow Specification
identified with an FS-ID does not exist, it <bcp14>MUST</bcp14> generate a P
CErr with Error-Type 30 (FlowSpec Error) and Error-value 4 (Unknown FlowSpec). <
/t>
<t>If the PCEP speaker does not understand or support the AFI in the FLOWS
PEC message, the PCEP peer
<bcp14>MUST</bcp14> respond with a PCErr message with Error-Type 30 (FlowSpe
c Error) and Error-value 2
(Malformed FlowSpec).</t> (Malformed FlowSpec).</t>
<t>The following TLVs can be used in the FLOWSPEC object:
</t>
<t>The following TLVs can be used in the FLOWSPEC object: <dl>
<list style="symbols"> <dt>Speaker Entity Identifier TLV:</dt>
<t>Speaker Entity Identifier TLV: As specified in <xref target="RFC8232"/>, the SPEAKER-ENTITY-ID TLV <dd> As specified in <xref target="RFC8232" format="default"/>, the SPEAK ER-ENTITY-ID TLV
encodes a unique identifier for the node that does not change during the lifetime of the PCEP encodes a unique identifier for the node that does not change during the lifetime of the PCEP
speaker. This is used to uniquely identify the FlowSpec originator and t speaker. This is used to uniquely identify the FlowSpec originator and t
hus used in conjunction hus is used in conjunction
with FS-ID to uniquely identify the FlowSpec information. This TLV MUST with the FS-ID to uniquely identify the FlowSpec information. This TLV <
be included. If the TLV bcp14>MUST</bcp14> be included. If the TLV
is missing, the PCEP peer MUST respond with a PCErr message with error-t is missing, the PCEP peer <bcp14>MUST</bcp14> respond with a PCErr messa
ype TBD8 (FlowSpec Error), ge with Error-Type 30 (FlowSpec Error) and
error-value 2 (Malformed FlowSpec). If more than one instance of this T Error-value 2 (Malformed FlowSpec). If more than one instance of this T
LV is present, the first MUST be LV is present, the first <bcp14>MUST</bcp14> be
processed and subsequence instances MUST be ignored.</t> processed, and subsequent instances <bcp14>MUST</bcp14> be ignored.</dd>
<dt>Flow Filter TLV (variable):</dt>
<t>Flow Filter TLV (variable): One TLV MAY be included. The Flow Filter TLV <dd> One TLV <bcp14>MAY</bcp14> be included. The Flow Filter TLV is <bcp1
is OPTIONAL when the R bit 4>OPTIONAL</bcp14> when the R bit
is set.</t> is set.</dd>
</dl>
<t>L2 Flow Filter TLV (variable): One TLV MAY be included. The L2 Flow Fil
ter TLV is OPTIONAL when
the R bit is set.</t>
</list></t>
<t>At least one Flow Filter TLV or one L2 Flow Filter TLV MUST be present when
the R bit is clear. If
both TLVs are missing when the R bit is clear, the PCEP peer MUST respond wi
th a PCErr message with
error-type TBD8 (FlowSpec Error) and error-value 2 (Malformed FlowSpec). A
Flow Filter TLV and a L2
Flow Filter TLV MAY both be present when filtering is based on both L3 and L
2 fields.</t>
</section>
<section title="Flow Filter TLV and L2 Flow Filter TLV" anchor="tlv">
<t>Two new PCEP TLVs are defined to convey Flow Specification filtering rules t
hat specify
what traffic is carried on a path. The TLVs follow the format of all PCEP T
LVs as defined
in <xref target="RFC5440" />. The Type field values come from the codepoint
space for
PCEP TLVs and has the value TBD4 for Flow Filter TLV and TBD9 for L2 Flow Fi
lter TLV.</t>
<t>The Value fields of the TLVs contain one or more sub-TLVs (the Flow Specific <t>The Flow Filter TLV <bcp14>MUST</bcp14> be present when the R bit is cl
ation TLVs or L2 ear. If the
Flow Specification TLVs) as defined in <xref target="subtlv" />, and they re TLV is missing when the R bit is clear, the PCEP peer <bcp14>MUST</bcp14> re
present the complete spond with a PCErr message with
Error-Type 30 (FlowSpec Error) and Error-value 2 (Malformed FlowSpec).</t>
<t>Filtering based on the L2 fields is out of scope of this document.</t>
</section>
<section anchor="tlv" numbered="true" toc="default">
<name>Flow Filter TLV</name>
<t>One new PCEP TLV is defined to convey Flow Specification filtering rule
s that specify
what traffic is carried on a path. The TLV follows the format of all PCEP T
LVs as defined
in <xref target="RFC5440" format="default"/>. The Type field values come fr
om the code point space for
PCEP TLVs and has the value 52 for Flow Filter TLV.</t>
<t>The Value field of the TLV contains one or more sub-TLVs (the Flow Spec
ification TLVs) as defined in <xref target="subtlv" format="default"/>, and they
represent the complete
definition of a Flow Specification for traffic to be placed on the tunnel. This tunnel is definition of a Flow Specification for traffic to be placed on the tunnel. This tunnel is
indicated by the PCEP message in which the PCEP FLOWSPEC object is carried. The set of Flow indicated by the PCEP message in which the PCEP FLOWSPEC object is carried. The set of Flow
Specification TLVs and L2 Flow Filter TLVs in a single instance of a Flow Fi lter TLV are Specification TLVs in a single instance of a Flow Filter TLV is
combined to indicate the specific Flow Specification. Note that the PCEP F LOWSPEC object can combined to indicate the specific Flow Specification. Note that the PCEP F LOWSPEC object can
include just one Flow Filter TLV, just one L2 Flow Filter TLV, or one of eac include just one Flow Filter TLV.</t>
h TLV.</t> <t>Further Flow Specifications can be included in a PCEP message by includ
ing additional
<t>Further Flow Specifications can be included in a PCEP message by including a FLOWSPEC objects.</t><t> In the future, there may be a desire to add support
dditional for L2 Flow
FLOWSPEC objects.</t> Specifications (such as described in <xref target="I-D.ietf-idr-flowspec-l2vp
n"/>).</t>
</section> </section>
<section anchor="subtlv" numbered="true" toc="default">
<section title="Flow Specification TLVs" anchor="subtlv"> <name>Flow Specification TLVs</name>
<t>The Flow Filter TLV carries one or more Flow Specification TLVs. The F
<t>The Flow Filter TLV carries one or more Flow Specification TLVs. The Flow S low Specification TLV
pecification TLV follows the format of all PCEP TLVs as defined in <xref target="RFC5440" for
follows the format of all PCEP TLVs as defined in <xref target="RFC5440" />. mat="default"/>. However, the Type values
However, the Type values are selected from a separate IANA registry (see <xref target="iana" format="
are selected from a separate IANA registry (see <xref target="iana" />) rath default"/>) rather than from the common
er than from the common
PCEP TLV registry.</t> PCEP TLV registry.</t>
<t>Type values are chosen so that there can be commonality with Flow Speci
fications defined for use
with BGP <xref target="RFC8955" format="default"/> <xref target="RFC8956" fo
rmat="default"/>. This
is possible because the BGP Flow Spec encoding uses a single octet to encode
the type, whereas PCEP uses
2 octets. Thus, the space of values for the Type field is partitioned as
shown in <xref target="fspectlvs" format="default"/>.</t>
<t>Type values are chosen so that there can be commonality with Flow Specificat <table anchor="fspectlvs">
ions defined for use <name>Flow Specification TLV Type Ranges</name>
with BGP <xref target="I-D.ietf-idr-rfc5575bis"/> and <xref target="I-D.ietf <thead>
-idr-flow-spec-v6" />. This <tr>
is possible because the BGP Flow Spec encoding uses a single octet to encode <th>Range</th>
the type where as PCEP uses <th>Description</th>
two octets. Thus the space of values for the Type field is partitioned as s </tr>
hown in <xref target="fspectlvs" />.</t> </thead>
<tbody>
<figure title="Flow Specification TLV Type Ranges" anchor="fspectlvs"> <tr>
<artwork> <td>0-255</td>
<![CDATA[ <td><t>Per BGP Flow Spec registry defined by
Range | <xref target="RFC8955"/> and
0 .. 255 | Per BGP registry defined by <xref target="RFC8956"/>.</t>
| [I-D.ietf-idr-rfc5575bis] and <t> Not to be allocated in this registry.</t></td>
| [I-D.ietf-idr-flow-spec-v6]. </tr>
| Not to be allocated in this registry. <tr>
| <td>256-65535</td>
256 .. 65535 | New PCEP Flow Specifications allocated according <td>New PCEP Flow Specifications allocated according
| to the registry defined in this document. to the registry defined in this document.</td>
]]> </tr>
</artwork> </tbody>
</figure> </table>
<t><xref target="RFC8955" format="default"/> is the reference for the "Flo
<t><xref target="I-D.ietf-idr-rfc5575bis"/> is the reference for the registry " w Spec Component Types" registry and defines the allocations it contains. <xref
Flow Spec Component Types" target="RFC8956" format="default"/> requested the creation of the "Flow Spec IP
and defines the allocations it contains. <xref target="I-D.ietf-idr-flow-sp v6 Component Types" registry, as well as its initial allocations. If the AFI (i
ec-v6"/> requested for another n the
registry "Flow Spec IPv6 Component Types" and requested initial allocations
in it. If the AFI (in the
FLOWSPEC object) is set to IPv4, the range 0..255 is as per "Flow Spec Compo nent Types" FLOWSPEC object) is set to IPv4, the range 0..255 is as per "Flow Spec Compo nent Types"
<xref target="I-D.ietf-idr-rfc5575bis"/>; if the AFI is set to IPv6, the ran <xref target="RFC8955" format="default"/>; if the AFI is set to IPv6, the ra
ge 0..255 is as per "Flow nge 0..255 is as per "Flow
Spec IPv6 Component Types" <xref target="I-D.ietf-idr-flow-spec-v6"/>.</t> Spec IPv6 Component Types" <xref target="RFC8956" format="default"/>.</t>
<t>The content of the Value field in each TLV is specific to the type/AFI and d escribes the parameters <t>The content of the Value field in each TLV is specific to the type/AFI an d describes the parameters
of the Flow Specification. The definition of the format of many of these Va lue fields is inherited of the Flow Specification. The definition of the format of many of these Va lue fields is inherited
from BGP specifications. Specifically, the inheritance is from <xref target from BGP specifications. Specifically, the inheritance is from <xref target
="I-D.ietf-idr-rfc5575bis"/> and ="RFC8955" format="default"/> and
<xref target="I-D.ietf-idr-flow-spec-v6"/>, but may also be inherited from f <xref target="RFC8956" format="default"/>, but it may also be inherited from
uture BGP specifications.</t> future BGP specifications.</t>
<t>When multiple Flow Specification TLVs are present in a single Flow Filter TL V they are combined to <t>When multiple Flow Specification TLVs are present in a single Flow Filter TLV, they are combined to
produce a more detailed specification of a flow. For examples and rules abo ut how this is achieved, produce a more detailed specification of a flow. For examples and rules abo ut how this is achieved,
see <xref target="I-D.ietf-idr-rfc5575bis"/>. As described in <xref target= see <xref target="RFC8955" format="default"/>. As described in <xref target
"I-D.ietf-idr-rfc5575bis"/> ="RFC8955" format="default"/>,
where it says "A given component type MAY (exactly once) be present in the F where it says "A given component type <bcp14>MAY</bcp14> (exactly once) be p
low Specification," a Flow resent in the Flow Specification", a Flow
Filter TLV MUST NOT contain more than one Flow Specification TLV of the same Filter TLV <bcp14>MUST NOT</bcp14> contain more than one Flow Specification
type: an implementation TLV of the same type: an implementation
that receives a PCEP message with a Flow Flter TLV that contains more than o that receives a PCEP message with a Flow Filter TLV that contains more than
ne Flow Specification TLV one Flow Specification TLV
of the same type MUST respond with a PCErr message with error-type TBD8 (Flo of the same type <bcp14>MUST</bcp14> respond with a PCErr message with Error
wSpec Error), error-value 2 -Type 30 (FlowSpec Error) and Error-value 2
(Malformed FlowSpec) and MUST NOT install the Flow Specification.</t> (Malformed FlowSpec) and <bcp14>MUST NOT</bcp14> install the Flow Specificat
ion.</t>
<t>An implementation that receives a PCEP message carrying a Flow Specification <t>An implementation that receives a PCEP message carrying a Flow Specific
TLV with a type value ation TLV with a type value
that it does not recognize or does not support MUST respond with a PCErr mes that it does not recognize or support <bcp14>MUST</bcp14> respond with a PCE
sage with error-type TBD8 rr message with Error-Type 30
(FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST NOT install (FlowSpec Error) and Error-value 1 (Unsupported FlowSpec) and <bcp14>MUST NO
the Flow Specification.</t> T</bcp14> install the Flow Specification.</t>
<t>When used in other protocols (such as BGP), these Flow Specifications a
<t>When used in other protocols (such as BGP), these Flow Specifications are al re also associated with actions
so associated with actions
to indicate how traffic matching the Flow Specification should be treated. In PCEP, however, the only to indicate how traffic matching the Flow Specification should be treated. In PCEP, however, the only
action is to associate the traffic with a tunnel and to forward matching tra ffic onto that path, so action is to associate the traffic with a tunnel and to forward matching tra ffic onto that path, so
no encoding of an action is needed.</t> no encoding of an action is needed.</t>
<t><xref target="priorities" format="default"/> describes how overlapping
<t><xref target="priorities" /> describes how overlapping Flow Specifications a Flow Specifications are prioritized and
re prioritized and
handled.</t> handled.</t>
<t>All Flow Specification TLVs with Types in the range 0 to 255 have value
<t>All Flow Specification TLVs with Types in the range 0 to 255 have Values def s defined
ined for use in BGP (for example, in <xref target="RFC8955" format="default"/> an
for use in BGP (for example, in <xref target="I-D.ietf-idr-rfc5575bis"/> and d
<xref target="I-D.ietf-idr-flow-spec-v6"/>) and are set using the BGP encodi <xref target="RFC8956" format="default"/>) and are set using the BGP encodin
ng, g
but without the type octet (the relevant information is in the but without the type octet (the relevant information is in the
Type field of the TLV). The Value field is padded with trailing Type field of the TLV). The Value field is padded with trailing
zeros to achieve 4-byte alignment.</t> zeros to achieve 4-byte alignment.</t>
<t>This document defines the following new types:
<t>This document defines the following new types: </t>
<table align="left" anchor="tlvFigthis">
<name>Flow Specification TLV Types Defined in this Document</name>
<thead>
<tr>
<th> Type </th>
<th> Description</th>
<th> Value Defined In</th>
</tr>
</thead>
<tbody>
<tr>
<figure title="Table of Flow Specification TLV Types defined in this document" a <td>256</td>
nchor="tlvFigthis"> <td>Route Distinguisher</td>
<artwork> <td>RFC 9168</td>
<![CDATA[ </tr>
+-------+-------------------------+-----------------------------+ <tr>
| Type | Description | Value defined in |
| | | |
+-------+-------------------------+-----------------------------+
| TBD5 | Route Distinguisher | [This.I-D] |
+-------+-------------------------+-----------------------------+
| TBD6 | IPv4 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+
| TBD7 | IPv6 Multicast Flow | [This.I-D] |
+-------+-------------------------+-----------------------------+
]]> <td>257</td>
</artwork> <td>IPv4 Multicast Flow</td>
</figure></t> <td>RFC 9168</td>
</tr>
<tr>
<t>To allow identification of a VPN in PCEP via a Route Distinguisher (RD) <x <td>258</td>
ref target="RFC4364"/>, <td>IPv6 Multicast Flow</td>
a new TLV - ROUTE-DISTINGUISHER TLV is defined in this document. A Flow S <td>RFC 9168</td>
pecification TLV with </tr>
Type TBD5 (ROUTE-DISTINGUISHER TLV) carries an RD Value, used to identify </tbody>
that other flow filter </table>
<t>To allow identification of a VPN in PCEP via a Route Distinguisher (RD)
<xref target="RFC4364" format="default"/>,
a new TLV, ROUTE-DISTINGUISHER TLV, is defined in this document. A Flow S
pecification TLV with
Type 256 (ROUTE-DISTINGUISHER TLV) carries an RD value, which is used to i
dentify that other flow filter
information (for example, an IPv4 destination prefix) is associated with a specific VPN identified information (for example, an IPv4 destination prefix) is associated with a specific VPN identified
by the RD. See <xref target="vpn-id" /> for further discussion of VPN ide by the RD. See <xref target="vpn-id" format="default"/> for further discu
ntification.</t> ssion of VPN identification.</t>
<figure anchor="rdtlv">
<figure title="The Format of the ROUTE-DISTINGUISHER TLV" anchor="rdtlv"> <name>The Format of the ROUTE-DISTINGUISHER TLV</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![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=[TBD5] | Length=8 | | Type=256 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Distinguisher | | Route Distinguisher |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The format of the RD is as per <xref target="RFC4364" format="default"/
>.</t>
<t>The format of RD is as per <xref target="RFC4364"/>.</t> <t>Although it may be possible to describe a multicast Flow Specification
from the
<t>Although it may be possible to describe a multicast Flow Specification from
the
combination of other Flow Specification TLVs with specific values, it is mor e convenient combination of other Flow Specification TLVs with specific values, it is mor e convenient
to use a dedicated Flow Specification TLV. Flow Specification TLVs with Typ e to use a dedicated Flow Specification TLV. Flow Specification TLVs with Typ e
values TBD6 and TBD7 are used to identify a multicast flow for IPv4 and IPv6 values 257 and 258 are used to identify a multicast flow for IPv4 and IPv6,
respectively. respectively.
The Value field is encoded as shown in <xref target="mcastfig" />.</t> The Value field is encoded as shown in <xref target="mcastfig" format="defau
lt"/>.</t>
<figure title="Multicast Flow Specification TLV Encoding" anchor="mcastfig"> <figure anchor="mcastfig">
<artwork> <name>Multicast Flow Specification TLV Encoding</name>
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|G| Src Mask Len | Grp Mask Len | | Reserved |S|G| Src Mask Len | Grp Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Address ~ ~ Source Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group multicast Address ~ ~ Group multicast Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure>
<t>The address fields and address mask lengths of the two Multicast Flow Specif <t>The address fields and address mask lengths of the two Multicast Flow S
ication TLVs pecification TLVs
contain source and group prefixes for matching against packet flows noting t contain source and group prefixes for matching against packet flows. Note th
hat the two address at the two address
fields are 32 bits for an IPv4 Multicast Flow and 128 bits for an IPv6 Multi cast Flow.</t> fields are 32 bits for an IPv4 Multicast Flow and 128 bits for an IPv6 Multi cast Flow.</t>
<t>The Reserved field <bcp14>MUST</bcp14> be set to zero and ignored on re
<t>The Reserved field MUST be set to zero and ignored on receipt.</t> ceipt.</t>
<t>Two bit flags (S and G) are defined to describe the multicast wildcardi
<t>Two bit flags (S and G) are defined to describe the multicast wildcarding in ng in use.
use. If the S bit is set, then source wildcarding is in use, and the values in th
If the S bit is set, then source wildcarding is in use and the values in the e Source Mask Length
Source Mask Length and Source Address fields <bcp14>MUST</bcp14> be ignored. If the G bit is s
and Source Address fields MUST be ignored. If the G bit is set, then group et, then group wildcarding is in
wildcarding is in use, and the values in the Group Mask Length and Group multicast Address fie
use and the values in the Group Mask Length and Group multicast Address fiel lds <bcp14>MUST</bcp14> be ignored.
ds MUST be ignored. The G bit <bcp14>MUST NOT</bcp14> be set unless the S bit is also set: if a
The G bit MUST NOT be set unless the S bit is also set: if a Multicast Flow Multicast Flow Specification TLV
Specification TLV is received with S bit = 0 and G bit = 1, the receiver <bcp14>MUST</bcp14> r
is received with S bit = 0 and G bit = 1 the receiver MUST respond with a PC espond with a PCErr with Error-Type 30 (FlowSpec Error) and Error-value 2 (Malfo
Err with Error-type rmed FlowSpec).</t>
TBD8 (FlowSpec Error) and error-value 2 (Malformed FlowSpec).</t> <t>The three multicast mappings may be achieved as follows:
</t>
<t>The three multicast mappings may be achieved as follows: <ul empty="true">
<li>(S, G) - S bit = 0, G bit = 0, the Source Address and Group multicast
<list style="empty"> Address prefixes are
both used to define the multicast flow.</li>
<t>(S, G) - S bit = 0, G bit = 0, the Source Address and Group multicast A <li>(*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix is u
ddress prefixes are sed to define the
both used to define the multicast flow.</t> multicast flow, but the Source Address prefix is ignored.</li>
<li>(*, *) - S bit = 1, G bit = 1, the Source Address and Group multicast
<t>(*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix is us Address prefixes are
ed to define the both ignored.</li>
multicast flow, but the Source Address prefix is ignored.</t> </ul>
</section>
<t>(*, *) = S bit = 1, G bit = 1, the Source Address and Group multicast A <section anchor="detailed" numbered="true" toc="default">
ddress prefixes are <name>Detailed Procedures</name>
both ignored.</t> <t>This section outlines some specific detailed procedures for using the p
rotocol extensions
</list></t>
<section title="L2 Flow Specification TLVs" anchor="L2-subtlv">
<t>The L2 Flow Filter TLV carries one or more L2 Flow Specification TLV. The
L2 Flow Specification TLV
follows the format of all PCEP TLVs as defined in <xref target="RFC5440"
/>. However, the Type values
are selected from a separate IANA registry (see <xref target="iana-2" />)
rather than from the common
PCEP TLV registry.</t>
<t>Type values are chosen so that there can be commonality with L2 Flow Spec
ifications defined for use
with BGP <xref target="I-D.ietf-idr-flowspec-l2vpn"/>. This is possible
because the BGP Flow Spec
encoding uses a single octet to encode the type where as PCEP uses two oc
tets. Thus the space of
values for the Type field is partitioned as shown in <xref target="L2-fsp
ectlvs" />.</t>
<figure title="L2 Flow Specification TLV Type Ranges" anchor="L2-fspectlvs">
<artwork>
<![CDATA[
Range |
---------------+-------------------------------------------------
0 .. 255 | Per BGP registry defined by
| [I-D.ietf-idr-flowspec-l2vpn].
| Not to be allocated in this registry.
|
256 .. 65535 | New PCEP Flow Specifications allocated according
| to the registry defined in this document.
]]>
</artwork>
</figure>
<t><xref target="I-D.ietf-idr-flowspec-l2vpn"/> is the reference for the regi
stry "L2 Flow Spec Component Types"
and defines the allocations it contains.</t>
<t>The content of the Value field in each TLV is specific to the type and des
cribes the parameters
of the Flow Specification. The definition of the format of many of these
Value fields is inherited
from BGP specifications. Specifically, the inheritance is from <xref targ
et="I-D.ietf-idr-flowspec-l2vpn"/>, but may also be inherited from future BGP sp
ecifications.</t>
<t>When multiple L2 Flow Specification TLVs are present in a single L2 Flow F
ilter TLV they are combined to
produce a more detailed specification of a flow. Similarly, when both Flow
Filter TLV and L2 Flow Filter TLV are present, they are combined to
produce a more detailed specification of a flow.</t>
<t>An implementation that receives a PCEP message carrying a L2 Flow Specific
ation TLV with a type value
that it does not recognize or does not support MUST respond with a PCErr m
essage with error-type TBD8
(FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST NOT instal
l the Flow Specification.</t>
<t>All L2 Flow Specification TLVs with Types in the range 0 to 255 have their
Values interpretted
as defined for use in BGP (for example, in <xref target="I-D.ietf-idr-flow
spec-l2vpn"/>) and are set using the BGP encoding,
but without the type octet (the relevant information is in the
Type field of the TLV). The Value field is padded with trailing
zeros to achieve 4-byte alignment.</t>
<t>This document defines no new types.</t>
<t>In the rest of the document when the Flow Specification is mentioned, it i
ncludes the L2 Flow Specifications as well.</t>
</section>
</section>
<section title="Detailed Procedures" anchor="detailed">
<t>This section outlines some specific detailed procedures for using the protoc
ol extensions
defined in this document.</t> defined in this document.</t>
<section anchor="default" numbered="true" toc="default">
<section title="Default Behavior and Backward Compatibility" anchor="default"> <name>Default Behavior and Backward Compatibility</name>
<t>The default behavior is that no Flow Specification is applied to a tu
<t>The default behavior is that no Flow Specification is applied to a tunnel nnel. That is,
. That is, the default is that the FLOWSPEC object is not used, as is the case in al
the default is that the FLOWSPEC object is not used as is the case in all l systems
systems
before the implementation of this specification.</t> before the implementation of this specification.</t>
<t>In this case, it is a local matter (such as through configuration) ho
<t>In this case, it is a local matter (such as through configuration) how tu w tunnel head ends
nnel head ends are instructed in terms of what traffic to place on a tunnel.</t>
are instructed what traffic to place on a tunnel.</t> <t><xref target="RFC5440" format="default"/> describes how receivers res
pond when they see unknown PCEP
<t><xref target="RFC5440"/> describes how receivers respond when they see un
known PCEP
objects.</t> objects.</t>
</section>
</section> <section anchor="composite" numbered="true" toc="default">
<name>Composite Flow Specifications</name>
<section title="Composite Flow Specifications" anchor="composite"> <t>Flow Specifications may be represented by a single Flow Specification
TLV or may require a
<t>Flow Specifications may be represented by a single Flow Specification TLV
or may require a
more complex description using multiple Flow Specification TLVs. For exam ple, a flow more complex description using multiple Flow Specification TLVs. For exam ple, a flow
indicated by a source-destination pair of IPv6 addresses would be describe d by the indicated by a source-destination pair of IPv6 addresses would be describe d by the
combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow Specifi cation TLVs.</t> combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow Specifi cation TLVs.</t>
</section>
</section> <section anchor="modify" numbered="true" toc="default">
<name>Modifying Flow Specifications</name>
<section title="Modifying Flow Specifications" anchor="modify"> <t>A PCE may want to modify a Flow Specification associated with a tunne
l, or a PCC may
<t>A PCE may want to modify a Flow Specification associated with a tunnel, or
a PCC may
want to report a change to the Flow Specification it is using with a tunne l.</t> want to report a change to the Flow Specification it is using with a tunne l.</t>
<t>It is important to identify the specific Flow Specification so it is
<t>It is important that the specific Flow Specification is identified so that clear that
it is clear that
this is a modification of an existing flow and not the addition of a new f low as described this is a modification of an existing flow and not the addition of a new f low as described
in <xref target="multiple" />. The FS-ID field of the PCEP FLOWSPEC objec t is used to in <xref target="multiple" format="default"/>. The FS-ID field of the PCE P FLOWSPEC object is used to
identify a specific Flow Specification in the context of the content of th e Speaker Entity identify a specific Flow Specification in the context of the content of th e Speaker Entity
Identifier TLV.</t> Identifier TLV.</t>
<t>When modifying a Flow Specification, all Flow Specification TLVs for
<t>When modifying a Flow Specification, all Flow Specification TLVs for the i the intended specification
ntended specification of the flow <bcp14>MUST</bcp14> be included in the PCEP FLOWSPEC object. T
of the flow MUST be included in the PCEP FLOWSPEC object. the FS-ID MUST b he FS-ID <bcp14>MUST</bcp14> be retained from the
e retained from the previous description of the flow, and the same Speaker Entity Identifier T
previous description of the flow, and the same Speaker Entity Identity TLV LV <bcp14>MUST</bcp14> be used.</t>
MUST be used.</t> </section>
<section anchor="multiple" numbered="true" toc="default">
</section> <name>Multiple Flow Specifications</name>
<t>It is possible that traffic from multiple flows will be placed on a s
<section title="Multiple Flow Specifications" anchor="multiple"> ingle tunnel. In some cases,
<t>It is possible that traffic from multiple flows will be placed on a single
tunnel. In some cases
it is possible to define these within a single PCEP FLOWSPEC object by wid ening the scope of a Flow it is possible to define these within a single PCEP FLOWSPEC object by wid ening the scope of a Flow
Specification TLV: for example, traffic to two destination IPv4 prefixes m ight be captured by a single Specification TLV: for example, traffic to two destination IPv4 prefixes m ight be captured by a single
Flow Specification TLV with type 'Destination' with a suitably adjusted pr efix. However, this is Flow Specification TLV with type "Destination" with a suitably adjusted pr efix. However, this is
unlikely to be possible in most scenarios, and it must be recalled that it is not permitted to include unlikely to be possible in most scenarios, and it must be recalled that it is not permitted to include
two Flow Specification TLVs of the same type within one Flow Filter TLV.</ t> two Flow Specification TLVs of the same type within one Flow Filter TLV.</ t>
<t>The normal procedure, therefore, is to carry each Flow Specification
<t>The normal procedure, therefore, is to carry each Flow Specification in it in its own PCEP FLOWSPEC object.
s own PCEP FLOWSPEC object.
Multiple objects may be present on a single PCEP message, or multiple PCEP messages may be used.</t> Multiple objects may be present on a single PCEP message, or multiple PCEP messages may be used.</t>
</section>
</section> <section anchor="addremove" numbered="true" toc="default">
<name>Adding and Removing Flow Specifications</name>
<section title="Adding and Removing Flow Specifications" anchor="addremove"> <t>The Remove bit in the PCEP FLOWSPEC object is left clear when a Flow
Specification is being
<t>The Remove bit in the PCEP FLOWSPEC object is left clear when a Flow Spec
ification is being
added or modified.</t> added or modified.</t>
<t>To remove a Flow Specification, a PCEP FLOWSPEC object is included wi
<t>To remove a Flow Specification, a PCEP FLOWSPEC object is included with t th the FS-ID matching the
he FS-ID matching the one being removed, and the R bit is set to indicate removal. In this cas
one being removed, and the R bit set to indicate removal. In this case i e, it is not necessary to
t is not necessary to
include any Flow Specification TLVs.</t> include any Flow Specification TLVs.</t>
<t>If the R bit is set and Flow Specification TLVs are present, an imple
<t>If the R bit is set and Flow Specification TLVs are present, an implement mentation <bcp14>MAY</bcp14> ignore them. If
ation MAY ignore them. If
the implementation checks the Flow Specification TLVs against those recor ded for the FS-ID and Speaker the implementation checks the Flow Specification TLVs against those recor ded for the FS-ID and Speaker
Entity Identity of the Flow Specification being removed and finds a misma Entity Identifier of the Flow Specification being removed and finds a mis
tch, the Flow Specification matching the FS-ID match, the Flow Specification matching the FS-ID
MUST still be removed and the implementation SHOULD record a local except <bcp14>MUST</bcp14> still be removed, and the implementation <bcp14>SHOUL
ion or log.</t> D</bcp14> record a local exception or log.</t>
</section>
</section> <section anchor="vpn-id" numbered="true" toc="default">
<name>VPN Identifiers</name>
<section title="VPN Identifiers" anchor="vpn-id"> <t>VPN instances are identified in BGP using RDs <xref target="RFC4364"
format="default"/>. These
<t>VPN instances are identified in BGP using Route Distinguishers (RDs) <xref
target="RFC4364"/>. These
values are not normally considered to have any meaning outside of the netw ork, and they are not encoded values are not normally considered to have any meaning outside of the netw ork, and they are not encoded
in data packets belonging to the VPNs. However, RDs provide a useful way of identifying VPN instances in data packets belonging to the VPNs. However, RDs provide a useful way of identifying VPN instances
and are often manually or automatically assigned to VPNs as they are provi sioned.</t> and are often manually or automatically assigned to VPNs as they are provi sioned.</t>
<t>Thus, the RD provides a useful way to indicate that traffic for a par
<t>Thus the RD provides a useful way to indicate that traffic for a particula ticular VPN should be placed on a
r VPN should be placed on a
given tunnel. The tunnel head end will need to interpret this Flow Specif ication not as a filter on given tunnel. The tunnel head end will need to interpret this Flow Specif ication not as a filter on
the fields of data packets, but using the other mechanisms that it already the fields of data packets but rather using the other mechanisms that it a
uses to identify VPN traffic. lready uses to identify VPN traffic.
This could be based on the incoming port (for port-based VPNs) or may leve These mechanisms could be based on the incoming port (for port-based VPNs)
rage knowledge of the VRF that or may leverage knowledge of the VPN Routing and Forwarding (VRF) that
is in use for the traffic.</t> is in use for the traffic.</t>
</section>
<section anchor="priorities" numbered="true" toc="default">
<name>Priorities and Overlapping Flow Specifications</name>
<t>Flow Specifications can overlap. For example, two different Flow Spe
cifications may be identical except
for the length of the prefix in the destination address. In these cases,
the PCC must determine how to
prioritize the Flow Specifications so as to know which path to assign pack
ets that match both Flow Specifications. That is, the PCC must assign a precede
nce to the Flow Specifications so that it checks
each incoming packet for a match in a predictable order.</t>
</section> <t>The processing of BGP Flow Specifications is described in
<xref target="RFC8955" format="default"/>. Section <xref target="RFC895
<section title="Priorities and Overlapping Flow Specifications" anchor="priorit 5" section="5.1" sectionFormat="bare"/> of
ies"> that document explains the order of traffic filtering rules to
be executed by an implementation of that specification.</t>
<t>Flow specifications can overlap. For example, two different flow specific <t>PCCs <bcp14>MUST</bcp14> apply the same ordering rules as defined in
ations may be identical except <xref target="RFC8955" format="default"/>.</t>
for the length of the prefix in the destination address. In these cases t <t>Furthermore, it is possible that Flow Specifications will be distribu
he PCC must determine how to ted
prioritize the flow specifications so as to know to which path to assign p
ackets that match both flow
specifications. That is, the PCC must assign a precedence to the flow spe
cifications so that it checks
each incoming packet for a match in a predictable order.</t>
<t>The processing of BGP Flow Specifications is described in <xref target="I-
D.ietf-idr-rfc5575bis"/>. Section 5.1 of that
document explains the order of traffic filtering rules to be executed by a
n implementation of that
specification.</t>
<t>PCCs MUST apply the same ordering rules as defined in <xref target="I-D.ie
tf-idr-rfc5575bis"/>.</t>
<t>Furthermore, it is possible that Flow Specifications will be distributed
by BGP as well as by PCEP as described in this document. In such by BGP as well as by PCEP as described in this document. In such
cases implementations supporting both approaches MUST apply the cases, implementations supporting both approaches <bcp14>MUST</bcp14> appl
prioritization and ordering rules as set out in <xref target="I-D.ietf-idr y the
-rfc5575bis" /> prioritization and ordering rules as set out in <xref target="RFC8955" for
mat="default"/>
regardless of which protocol distributed the Flow Specifications. regardless of which protocol distributed the Flow Specifications.
However, implementations MAY provide a configuration control to However, implementations <bcp14>MAY</bcp14> provide a configuration contro
allow one protocol to take precedence over the other as this may be l to
allow one protocol to take precedence over the other; this may be
particularly useful if the Flow Specifications make identical matches particularly useful if the Flow Specifications make identical matches
on traffic, but have different actions. It is RECOMMENDED that when on traffic but have different actions. It is <bcp14>RECOMMENDED</bcp14> t
hat a message be
logged for the operator to understand the behavior when
two Flow Specifications distributed by different protocols overlap, two Flow Specifications distributed by different protocols overlap,
and especially when one acts to replace another, that a message be especially when one acts to replace another.</t>
logged for the operator to understand the behaviour.</t> <t><xref target="mg-mxfspec" format="default"/> of this document covers
manageability considerations relevant to the
<t><xref target="mg-mxfspec"/> of this document covers manageability consider prioritized ordering of Flow Specifications.</t>
ations relevant to the <t>An implementation that receives a PCEP message carrying a Flow Specif
prioritized ordering of flow specifications.</t> ication that it cannot resolve
<t>An implementation that receives a PCEP message carrying a Flow Specificati
on that it cannot resolve
against other Flow Specifications already installed (for example, because the new Flow Specification has against other Flow Specifications already installed (for example, because the new Flow Specification has
irresolvable conflicts with other Flow Specifications that are already ins irresolvable conflicts with other Flow Specifications that are already ins
talled) MUST respond with a PCErr talled) <bcp14>MUST</bcp14> respond with a PCErr
message with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable message with Error-Type 30 (FlowSpec Error) and Error-value 3 (Unresolvabl
Conflict) and MUST NOT install the e Conflict) and <bcp14>MUST NOT</bcp14> install the
Flow Specification.</t> Flow Specification.</t>
</section>
</section> </section>
<section anchor="messages" numbered="true" toc="default">
</section> <name>PCEP Messages</name>
<t>This section describes the format of messages that contain FLOWSPEC obj
<section title="PCEP Messages" anchor="messages"> ects. The
only difference from previous message formats is the inclusion of that objec
<t>This section describes the format of messages that contain FLOWSPEC objects. t.</t>
The <t>The figures in this section use the notation defined in <xref target="R
only difference to previous message formats is the inclusion of that object. FC5511" format="default"/>.</t>
</t> <t>The FLOWSPEC object is <bcp14>OPTIONAL</bcp14> and <bcp14>MAY</bcp14> b
e carried in the PCEP messages.</t>
<t>The figures in this section use the notation defined in <xref target="RFC551 <t>The PCInitiate message is defined in <xref target="RFC8281" format="def
1" />.</t> ault"/> and updated
<t>The FLOWSPEC object is OPTIONAL and MAY be carried in the PCEP messages.</t>
<t>The PCInitiate message is defined in <xref target="RFC8281" /> and updated
as below:</t> as below:</t>
<sourcecode type="rbnf"><![CDATA[
<figure>
<artwork>
<![CDATA[
<PCInitiate Message> ::= <Common Header> <PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list> <PCE-initiated-lsp-list>
Where: Where:
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request> <PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>] [<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= <PCE-initiated-lsp-request> ::=
( <PCE-initiated-lsp-instantiation>| ( <PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion> ) <PCE-initiated-lsp-deletion> )
<PCE-initiated-lsp-instantiation> ::= <SRP> <PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP> <LSP>
[<END-POINTS>] [<END-POINTS>]
<ERO> <ERO>
[<attribute-list>] [<attribute-list>]
[<flowspec-list>] [<flowspec-list>]
Where: Where:
<flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>]
]]> ]]></sourcecode>
</artwork> <t>The PCUpd message is defined in <xref target="RFC8231" format="default"
</figure> /> and
<t>The PCUpd message is defined in <xref target="RFC8231" /> and
updated as below:</t> updated as below:</t>
<sourcecode type="rbnf"><![CDATA[
<figure>
<artwork>
<![CDATA[
<PCUpd Message> ::= <Common Header> <PCUpd Message> ::= <Common Header>
<update-request-list> <update-request-list>
Where: Where:
<update-request-list> ::= <update-request> <update-request-list> ::= <update-request>
[<update-request-list>] [<update-request-list>]
<update-request> ::= <SRP> <update-request> ::= <SRP>
<LSP> <LSP>
<path> <path>
[<flowspec-list>] [<flowspec-list>]
Where: Where:
<path>::= <intended-path><intended-attribute-list> <path>::= <intended-path><intended-attribute-list>
<flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>]
]]> ]]></sourcecode>
</artwork> <t>The PCRpt message is defined in <xref target="RFC8231" format="default"
</figure> /> and
<t>The PCRpt message is defined in <xref target="RFC8231"/> and
updated as below:</t> updated as below:</t>
<sourcecode type="rbnf"><![CDATA[
<figure>
<artwork>
<![CDATA[
<PCRpt Message> ::= <Common Header> <PCRpt Message> ::= <Common Header>
<state-report-list> <state-report-list>
Where: Where:
<state-report-list> ::= <state-report>[<state-report-list>] <state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>] <state-report> ::= [<SRP>]
<LSP> <LSP>
<path> <path>
[<flowspec-list>] [<flowspec-list>]
Where: Where:
<path>::= <intended-path> <path>::= <intended-path>
[<actual-attribute-list><actual-path>] [<actual-attribute-list><actual-path>]
<intended-attribute-list> <intended-attribute-list>
<flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>]
]]> ]]></sourcecode>
</artwork> <t>The PCReq message is defined in <xref target="RFC5440" format="default"
</figure> /> and updated in <xref target="RFC8231" format="default"/>;
it is further updated below for a Flow Specification:</t>
<t>The PCReq message is defined in <xref target="RFC5440"/> and updated in <xre <sourcecode type="rbnf"><![CDATA[
f target="RFC8231"/>,
it is further updated below for flow specification:</t>
<figure>
<artwork>
<![CDATA[
<PCReq Message>::= <Common Header> <PCReq Message>::= <Common Header>
[<svec-list>] [<svec-list>]
<request-list> <request-list>
Where: Where:
<svec-list>::= <SVEC>[<svec-list>] <svec-list>::= <SVEC>[<svec-list>]
<request-list>::= <request>[<request-list>] <request-list>::= <request>[<request-list>]
<request>::= <RP> <request>::= <RP>
skipping to change at line 1004 skipping to change at line 784
[<LSPA>] [<LSPA>]
[<BANDWIDTH>] [<BANDWIDTH>]
[<metric-list>] [<metric-list>]
[<RRO>[<BANDWIDTH>]] [<RRO>[<BANDWIDTH>]]
[<IRO>] [<IRO>]
[<LOAD-BALANCING>] [<LOAD-BALANCING>]
[<flowspec-list>] [<flowspec-list>]
Where: Where:
<flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>]
]]> ]]></sourcecode>
</artwork> <t>The PCRep message is defined in <xref target="RFC5440" format="default"
</figure> /> and updated in
<xref target="RFC8231" format="default"/>; it is further updated below for a
<t>The PCRep message is defined in <xref target="RFC5440" /> and updated in Flow
<xref target="RFC8231" />, it is further updated below for flow Specification:</t>
specification:</t> <sourcecode type="rbnf"><![CDATA[
<figure>
<artwork>
<![CDATA[
<PCRep Message> ::= <Common Header> <PCRep Message> ::= <Common Header>
<response-list> <response-list>
Where: Where:
<response-list>::=<response>[<response-list>] <response-list>::=<response>[<response-list>]
<response>::=<RP> <response>::=<RP>
[<LSP>] [<LSP>]
[<NO-PATH>] [<NO-PATH>]
[<attribute-list>] [<attribute-list>]
[<path-list>] [<path-list>]
[<flowspec-list>] [<flowspec-list>]
Where: Where:
<flowspec-list> ::= <FLOWSPEC> [<flowspec-list>] <flowspec-list> ::= <FLOWSPEC> [<flowspec-list>]
]]> ]]></sourcecode>
</artwork> </section>
</figure> <section numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>This document requests that IANA allocate code points for the protocol
elements
<section title="IANA Considerations">
<t>IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" regist
ry.
This document requests IANA actions to allocate code points for the protocol
elements
defined in this document.</t> defined in this document.</t>
<section numbered="true" toc="default">
<section title="PCEP Objects"> <name>PCEP Objects</name>
<t>IANA maintains a subregistry called "PCEP Objects" within the "Path C
<t>Each PCEP object has an Object-Class and an Object-Type. IANA maintains a omputation Element Protocol
subregistry called "PCEP Objects". IANA is requested to make an assignmen (PCEP) Numbers" registry. Each PCEP object has an Object-Class and an Object-
t from this Type, and IANA has allocated new code points in this subregistry as follows:</t>
subregistry as follows:</t> <table align="left">
<name>PCEP Objects Subregistry Additions</name>
<figure> <thead>
<artwork> <tr>
<![CDATA[ <th>Object-Class Value</th>
Object-Class | Value Name | Object-Type | Reference <th>Name</th>
TBD3 | FLOWSPEC | 0: Reserved | [This.I-D] <th>Object-Type</th>
| | 1: Flow Specification | [This.I-D] <th>Reference</th>
]]> </tr>
</artwork> </thead>
</figure> <tbody>
<tr>
<section title="PCEP FLOWSPEC Object Flag Field"> <td rowspan="2">43</td>
<td rowspan="2">FLOWSPEC</td>
<t>This document requests that a new sub-registry, named "FLOWSPEC Object <td>0: Reserved</td>
Flag Field", is created within the "Path Computation Element Protocol <td>RFC 9168</td>
</tr>
<tr>
<td>1: Flow Specification</td>
<td>RFC 9168</td>
</tr>
</tbody>
</table>
<section numbered="true" toc="default">
<name>PCEP FLOWSPEC Object Flag Field</name>
<t>This document requests that a new subregistry, "FLOWSPEC Object
Flag Field", be created within the "Path Computation Element Protocol
(PCEP) Numbers" registry to manage the Flag field of the FLOWSPEC (PCEP) Numbers" registry to manage the Flag field of the FLOWSPEC
object. New values are to be assigned by Standards Action <xref target= "RFC8126"/>. object. New values are to be assigned by Standards Action <xref target= "RFC8126" format="default"/>.
Each bit should be tracked with the following qualities: Each bit should be tracked with the following qualities:
<list style="symbols"> </t>
<t>Bit number (counting from bit 0 as the most significant bit)</t> <ul spacing="normal">
<t>Capability description</t> <li>Bit number (counting from bit 0 as the most significant bit)</li
<t>Defining RFC</t> >
</list></t> <li>Capability description</li>
<li>Defining RFC</li>
<t>The initial population of this registry is as follows:</t> </ul>
<t>The initial population of this registry is as follows:</t>
<figure> <table align="left">
<artwork> <name>Initial Contents of the FLOWSPEC Object Flag Field Registry</na
<![CDATA[ me>
Bit | Description | Reference <thead>
-----+--------------------+------------- <tr>
0-5 | Unnassigned | <th>Bit</th>
6 | LPM (L bit) | [This.I-D] <th>Description</th>
7 | Remove (R bit) | [This.I-D] <th>Reference</th>
]]> </tr>
</artwork> </thead>
</figure> <tbody>
<tr>
</section> <td>0-5</td>
<td>Unassigned</td>
</section> <td></td>
</tr>
<tr>
<td>6</td>
<td>LPM (L bit)</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>7</td>
<td> Remove (R bit)</td>
<td>RFC 9168</td>
</tr>
</tbody>
</table>
<section title="PCEP TLV Type Indicators"> </section>
</section>
<section numbered="true" toc="default">
<name>PCEP TLV Type Indicators</name>
<t>IANA maintains a subregistry called "PCEP TLV Type Indicators" within
the "Path Computation Element Protocol (PCEP) Numbers" registry. IANA has made
the following allocations in this subregistry:</t>
<t>IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA is r <table align="left">
equested to <name>PCEP TLV Type Indicators Subregistry Additions</name>
make an assignment from this subregistry as follows:</t> <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th> Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>51</td>
<td>PCE-FLOWSPEC-CAPABILITY TLV</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>52</td>
<td>FLOW FILTER TLV</td>
<td>RFC 9168</td>
</tr>
</tbody>
</table>
<figure> </section>
<artwork> <section anchor="iana" numbered="true" toc="default">
<![CDATA[ <name>Flow Specification TLV Type Indicators</name>
Value | Meaning | Reference <t>IANA has created a new subregistry called "PCEP Flow Specification TL
TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] V Type Indicators" within the "Path Computation Element Protocol (PCEP) Numbers"
TBD4 | FLOW FILTER TLV | [This.I-D] registry.</t>
TBD9 | L2 FLOW FILTER TLV | [This.I-D] <t>Allocations from this registry are to be made according to the follow
]]> ing assignment policies <xref target="RFC8126" format="default"/>:</t>
</artwork>
</figure>
</section>
<section title="Flow Specification TLV Type Indicators" anchor="iana"> <table align="left">
<name>Registration Procedures for the PCEP Flow Specification TLV Type
Indicators Subregistry</name>
<thead>
<tr>
<th>Range</th>
<th>Registration Procedures</th>
</tr>
</thead>
<tbody>
<tr>
<td>0-255</td>
<td><t>Reserved - must not be allocated.</t>
<t>Usage mirrors the BGP Flow Spec registry
<xref target="RFC8955"/> <xref target="RFC8956"/>.</t></td>
</tr>
<tr>
<t>IANA is requested to create a new subregistry call the "PCEP Flow Specific <td>256-64506</td>
ation TLV Type Indicators" registry.</t> <td>Specification Required</td>
</tr>
<tr>
<t>Allocations from this registry are to be made according to the following a <td>64507-65531</td>
ssignment policies <xref target="RFC8126" />:</t> <td>First Come First Served</td>
</tr>
<tr>
<figure> <td>65532-65535</td>
<artwork> <td>Experimental Use</td>
<![CDATA[ </tr>
Range | Assignment policy </tbody>
0 .. 255 | Reserved - must not be allocated. </table>
| Usage mirrors the BGP FlowSpec registry
| [I-D.ietf-idr-rfc5575bis] and
| [I-D.ietf-idr-flow-spec-v6].
|
256 .. 64506 | Specification Required
|
64507 .. 65531 | First Come First Served
|
65532 .. 65535 | Experimental
]]>
</artwork>
</figure>
<t>IANA is requested to pre-populate this registry with values defined in thi s <t>IANA has populated this registry with values defined in this
document as follows, taking the new values from the range 256 to 64506:</t > document as follows, taking the new values from the range 256 to 64506:</t >
<table align="left">
<name>Initial Contents of the PCEP Flow Specification TLV Type Indicators
Subregistry</name>
<thead>
<tr>
<th>Value</th>
<th>Meaning</th>
</tr>
</thead>
<tbody>
<tr>
<figure> <td>256</td>
<artwork> <td>Route Distinguisher</td>
<![CDATA[ </tr>
Value | Meaning <tr>
TBD5 | Route Distinguisher
TBD6 | IPv4 Multicast
TBD7 | IPv6 Multicast
]]>
</artwork>
</figure>
</section>
<section title="L2 Flow Specification TLV Type Indicators" anchor="iana-2">
<t>IANA is requested to create a new subregistry called the "PCEP L2 Flow Spe
cification TLV Type Indicators" registry.</t>
<t>Allocations from this registry are to be made according to the following a
ssignment policies <xref target="RFC8126" />:</t>
<figure>
<artwork>
<![CDATA[
Range | Assignment policy
---------------+---------------------------------------------------
0 .. 255 | Reserved - must not be allocated.
| Usage mirrors the BGP L2 FlowSpec registry
| [I-D.ietf-idr-flowspec-l2vpn].
|
256 .. 64506 | Specification Required
|
64507 .. 65531 | First Come First Served
|
65532 .. 65535 | Experimental
]]>
</artwork>
</figure>
</section>
<section title="PCEP Error Codes">
<t>IANA maintains a subregistry called "PCEP-ERROR Object Error Types and Val
ues". Entries
in this subregistry are described by Error-Type and Error-value. IANA is
requested to
make the following assignment from this subregistry:</t>
<figure>
<artwork>
<![CDATA[
Error-| Meaning | Error-value | Reference
Type | | |
TBD8 | FlowSpec error | 0: Unassigned | [This.I-D]
| | 1: Unsupported FlowSpec | [This.I-D]
| | 2: Malformed FlowSpec | [This.I-D]
| | 3: Unresolvable Conflict | [This.I-D]
| | 4: Unknown FlowSpec | [This.I-D]
| | 5: Unsupported LPM Route | [This.I-D]
| | 6-255: Unassigned | [This.I-D]
]]>
</artwork>
</figure>
</section>
<section title="PCE Capability Flag">
<t>IANA maintains a subregistry called "Open Shortest Path First v2 (OSPFv2)
Parameters"
with a sub-registry called "Path Computation Element (PCE) Capability Flag
s". IANA is
requested to assign a new capability bit from this registry as follows:</t
>
<figure>
<artwork>
<![CDATA[
Bit | Capability Description | Reference
TBD1 | FlowSpec | [This.I-D]
]]>
</artwork>
</figure>
</section>
</section>
<section title="Implementation Status" anchor="imps">
<t>[NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942
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"/>. The description of implementations in this secti
on is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and worki
ng
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 the -12 version of this document, there are no known <td>257</td>
implementations of this mechanism. It is believed that two vendors are <td> IPv4 Multicast</td>
considering prototype implementations, but these plans are too vague to </tr>
make any further assertions.</t> <tr>
<td>258</td>
<td>IPv6 Multicast</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<name>PCEP Error Codes</name>
<t>IANA maintains a subregistry called "PCEP-ERROR Object Error Types an
d Values" within the "Path Computation Element Protocol (PCEP) Numbers" registry
. Entries
in this subregistry are described by Error-Type and Error-value. IANA has
added the following assignment to this subregistry:</t>
<table align="left">
<name>PCEP-ERROR Object Error Types and Values Subregistry Additions</nam
e>
<thead>
<tr>
<th>Error-Type</th>
<th>Meaning</th>
<th>Error-value</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="7">30</td>
<td rowspan="7">FlowSpec error</td>
<td>0: Unassigned</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>1: Unsupported FlowSpec</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>2: Malformed FlowSpec</td>
<td>RFC 9168</td>
</tr>
<tr>
<section title="Security Considerations" anchor="Security"> <td>3: Unresolvable Conflict</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>4: Unknown FlowSpec</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>5: Unsupported LPM Route</td>
<td>RFC 9168</td>
</tr>
<tr>
<td>6-255: Unassigned</td>
<td>RFC 9168</td>
</tr>
</tbody>
</table>
<t>We may assume that a system that utilizes a remote PCE is subject to a numbe </section>
r of <section numbered="true" toc="default">
<name>PCE Capability Flag</name>
<t>IANA has registered a new capability bit in the OSPF Parameters "Path
Computation Element (PCE) Capability Flags" registry as follows:</t>
<table align="left">
<name>Path Computation Element (PCE) Capability Flags Registry Addition
s</name>
<thead>
<tr>
<th>Bit</th>
<th>Capability Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>16</td>
<td>FlowSpec</td>
<td>RFC 9168</td>
</tr>
</tbody>
</table>
</section>
</section>
<section anchor="Security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>We may assume that a system that utilizes a remote PCE is subject to a
number of
vulnerabilities that could allow spurious LSPs or SR paths to be established or that vulnerabilities that could allow spurious LSPs or SR paths to be established or that
could result in existing paths being modified or torn down. Such systems, t herefore, could result in existing paths being modified or torn down. Such systems, t herefore,
apply security considerations as described in <xref target="RFC5440" />, apply security considerations as described in <xref target="RFC5440" format=
Section 2.5 of <xref target="RFC6952" />, <xref target="RFC8253" />, and "default"/>,
<xref target="I-D.ietf-idr-rfc5575bis" />.</t> <xref target="RFC6952" section="2.5" sectionFormat="of"/>, <xref target="RFC
8253" format="default"/>, and
<t>The description of Flow Specifications associated with paths set up or contr <xref target="RFC8955" format="default"/>.</t>
olled by a <t>The description of Flow Specifications associated with paths set up or
PCE add a further detail that could be attacked without tearing down LSPs or controlled by a
SR paths, PCE adds a further detail that could be attacked without tearing down LSPs o
but causing traffic to be misrouted within the network. Therefore, the use r SR paths
of the security but causes traffic to be misrouted within the network. Therefore, the use o
f the security
mechanisms for PCEP referenced above is important.</t> mechanisms for PCEP referenced above is important.</t>
<t>Visibility into the information carried in PCEP does not have direct pr
<t>Visibility into the information carried in PCEP does not have direct privacy ivacy concerns for
concerns for end users' data; however, knowledge of how data is routed in a network may m
end-users&apos; data, however, knowledge of how data is routed in a network ake that
may make that
data more vulnerable. Of course, the ability to interfere with the way data is routed also data more vulnerable. Of course, the ability to interfere with the way data is routed also
makes the data more vulnerable. Furthermore, knowledge of the connected end -points (such as makes the data more vulnerable. Furthermore, knowledge of the connected end points (such as
multicast receivers or VPN sites) is usually considered private customer inf ormation. Therefore, multicast receivers or VPN sites) is usually considered private customer inf ormation. Therefore,
implementations or deployments concerned with protecting privacy MUST apply implementations or deployments concerned with protecting privacy <bcp14>MUST
the mechanisms described </bcp14> apply the mechanisms described
in the documents referenced above: in particular to secure the PCEP session in the documents referenced above, in particular, to secure the PCEP session
using IPSec per Sections using IPsec per Sections
10.4 to 10.6 of <xref target="RFC5440" /> or TLS per <xref target="RFC8253" <xref target="RFC5440" section="10.4" sectionFormat="bare"/> to <xref targe
/>. Note that TCP-MD5 t="RFC5440" section="10.6" sectionFormat="bare"/> of <xref target="RFC5440"/> or
security as originally suggested in <xref target="RFC5440" /> does not provi TLS per <xref target="RFC8253" format="default"/>. Note that TCP-MD5
de sufficient security security as originally suggested in <xref target="RFC5440" format="default"/
or privacy guarantees, and SHOULD NOT be relied upon.</t> > does not provide sufficient security
or privacy guarantees and <bcp14>SHOULD NOT</bcp14> be relied upon.</t>
<t>Experience with Flow Specifications in BGP systems indicates that they can b <t>Experience with Flow Specifications in BGP systems indicates that they
ecome complex and can become complex and
that the overlap of Flow Specifications installed in different orders can le ad to unexpected that the overlap of Flow Specifications installed in different orders can le ad to unexpected
results. Although this is not directly a security issue per se, the confusi on and unexpected results. Although this is not directly a security issue per se, the confusi on and unexpected
forwarding behavior may be engineered or exploited by an attacker. Furtherm ore, this complexity forwarding behavior may be engineered or exploited by an attacker. Furtherm ore, this complexity
might give rise to a situation where the forwarding behaviors might create g aps in the monitoring might give rise to a situation where the forwarding behaviors might create g aps in the monitoring
and inspection of particular traffic or provide a path that avoids expected mitigations. Therefore, and inspection of particular traffic or provide a path that avoids expected mitigations. Therefore,
implementers and operators SHOULD pay careful attention to the Manageability implementers and operators <bcp14>SHOULD</bcp14> pay careful attention to th
Considerations described e manageability considerations described
in <xref target="Manage" /> and familiarize themselves with the careful expl in <xref target="Manage" format="default"/> and familiarize themselves with
anations in the careful explanations in
<xref target="I-D.ietf-idr-rfc5575bis" />.</t> <xref target="RFC8955" format="default"/>.</t>
</section>
</section> <section anchor="Manage" numbered="true" toc="default">
<name>Manageability Considerations</name>
<section title="Manageability Considerations" anchor="Manage"> <t>The feature introduced by this document enables operational manageabili
ty of networks operated in
<t>The feature introduced by this document enables operational manageability o conjunction with a PCE and using PCEP. In the case of a stateful active
f networks operated in PCE or with PCE-initiated services, in the absence of this feature, additio
conjunction with a PCE and using PCEP. Without this feature, but in the ca nal manual configuration is needed to tell the head ends
se of a stateful active
PCE or with PCE-initiated services, additional manual configuration is need
ed to tell the head-ends
what traffic to place on the network services (LSPs, SR paths, etc.).</t> what traffic to place on the network services (LSPs, SR paths, etc.).</t>
<t>This section follows the advice and guidance of <xref target="RFC6123"
<t>This section follows the advice and guidance of <xref target="RFC6123" />.< format="default"/>.</t>
/t> <section anchor="mg-mxfspec" numbered="true" toc="default">
<name>Management of Multiple Flow Specifications</name>
<section title="Management of Multiple Flow Specifications" anchor="mg-mxfspec <t>Experience with Flow Specification in BGP suggests that there can be
"> a lot of complexity when
two or more Flow Specifications overlap. This can arise, for example, wi
<t>Experience with flow specification in BGP suggests that there can be a lo th addresses indicated
t of complexity when using prefixes and could cause confusion about what traffic should be pla
two or more flow specifications overlap. This can arise, for example, wi ced on which path. Unlike
th addresses indicated the behavior in a distributed routing system, it is not important to the
using prefixes, and could cause confusion about what traffic should be pl routing stability and consistency
aced on which path. Unlike
the behavior in a distributed routing system, it is not important to the
routing stablity and consistency
of the network that each head-end implementation applies the same rules t o disambiguate overlapping Flow of the network that each head-end implementation applies the same rules t o disambiguate overlapping Flow
Specifications, but it is important that: Specifications, but it is important that:
<list style="symbols"> </t>
<t>A network operator can easily find out what traffic is being placed <ul spacing="normal">
on which path and why. This <li>a network operator can easily find out what traffic is being place
will facilitate analysis of the network and diagnosis of faults.</t> d on which path and why. This
<t>A PCE is able to correctly predict the effect of instructions it giv will facilitate analysis of the network and diagnosis of faults.</li
es to a PCC. This will >
<li>a PCE be able to correctly predict the effect of instructions it g
ives to a PCC. This will
ensure that traffic is correctly placed on the network without causi ng congestion or other ensure that traffic is correctly placed on the network without causi ng congestion or other
network inefficiencies, and that traffic is correctly delivered.</t> network inefficiencies and that traffic is correctly delivered.</li>
</list></t> </ul>
<t>To that end, a PCC <bcp14>MUST</bcp14> enable an operator to view the
<t>To that end, a PCC MUST enable an operator to view the the Flow Specifica Flow Specifications that it has installed,
tions that it has installed, and these <bcp14>MUST</bcp14> be presented in order of precedence such th
and these MUST be presented in order of precedence such that when two Flo at when two Flow Specifications overlap,
w Specifications overlap,
the one that will be serviced with higher precedence is presented to the operator first.</t> the one that will be serviced with higher precedence is presented to the operator first.</t>
<t>A discussion of precedence ordering for Flow Specifications is found
<t>A discussion of precedence ordering for flow specifications is found in < in <xref target="priorities" format="default"/>.</t>
xref target="priorities"/>.</t> </section>
<section anchor="mg-control" numbered="true" toc="default">
</section> <name>Control of Function through Configuration and Policy</name>
<t>Support for the function described in this document implies that a fu
<section title="Control of Function through Configuration and Policy" anchor=" nctional element that
mg-control"> is capable of requesting that a PCE compute and control a path is also ab
le to configure the
<t>Support for the function described in this document implies that a functi
onal element that
is capable of requesting a PCE to compute and control a path is also able
to configure the
specification of what traffic should be placed on that path. Where there is a human involved specification of what traffic should be placed on that path. Where there is a human involved
in this action, configuration of the Flow Specification must be available through an interface in this action, configuration of the Flow Specification must be available through an interface
(such as a graphical user interface or a command line interface). Where a distinct software (such as a graphical user interface or a Command Line Interface). Where a distinct software
component (i.e., one not co-implemented with the PCE) is used, a protocol mechanism will be component (i.e., one not co-implemented with the PCE) is used, a protocol mechanism will be
required that could be PCEP itself or could be a data model such as exten required that could be PCEP itself or a data model, such as extensions to
sions to the YANG the YANG
model for requesting path computation <xref target="I-D.ietf-teas-yang-pa model for requesting path computation <xref target="I-D.ietf-teas-yang-pa
th-computation" />.</t> th-computation" format="default"/>.</t>
<t>Implementations <bcp14>MAY</bcp14> be constructed with a configurable
<t>Implementations MAY be constructed with a configurable switch to say whet switch to indicate whether they support
her they support the functions defined in this document. Otherwise, such implementations
the functions defined in this document. Otherwise, such implementations <bcp14>MUST</bcp14> indicate
MUST indicate that they support the function as described in <xref target="cap" format=
that they support the function as described in <xref target="cap" />. If "default"/>. If an implementation
an implementation allows configurable support of this function, that support <bcp14>MAY</bc
supports configurable support of this function, that support MAY be confi p14> be configurable per peer or
gurable per peer or
once for the whole implementation.</t> once for the whole implementation.</t>
<t>As mentioned in <xref target="mg-mxfspec" format="default"/>, a PCE i
<t>As mentioned in <xref target="mg-mxfspec" />, a PCE implementation SHOULD mplementation <bcp14>SHOULD</bcp14> provide a mechanism
provide a mechanism
to configure variations in the precedence ordering of Flow Specifications per PCC.</t> to configure variations in the precedence ordering of Flow Specifications per PCC.</t>
</section>
</section> <section anchor="mg-model" numbered="true" toc="default">
<name>Information and Data Models</name>
<section title="Information and Data Models" anchor="mg-model"> <t>The YANG model in <xref target="I-D.ietf-pce-pcep-yang" format="defau
lt"/> can be used to model and monitor
<t>The YANG model in <xref target="I-D.ietf-pce-pcep-yang" /> can be used to
model and monitor
PCEP states and messages. To make that YANG model useful for the extensi ons described in PCEP states and messages. To make that YANG model useful for the extensi ons described in
this document, it would need to be augmented to cover the new protocol el ements.</t> this document, it would need to be augmented to cover the new protocol el ements.</t>
<t>Similarly, as noted in <xref target="mg-control" format="default"/>,
<t>Similarly, as noted in <xref target="mg-control" />, the YANG model defin the YANG model defined in
ed in <xref target="I-D.ietf-teas-yang-path-computation" format="default"/> cou
<xref target="I-D.ietf-teas-yang-path-computation" /> could be extended t ld be extended to allow the specification
o allow specification
of Flow Specifications.</t> of Flow Specifications.</t>
<t>Finally, as mentioned in <xref target="mg-mxfspec" format="default"/>
<t>Finally, as mentioned in <xref target="mg-mxfspec" />, a PCC implementati , a PCC implementation <bcp14>SHOULD</bcp14> provide
on SHOULD provide
a mechanism to allow an operator to read the Flow Specifications from a P CC and to a mechanism to allow an operator to read the Flow Specifications from a P CC and to
understand in what order they will be executed. This could be achieved u sing a new YANG understand in what order they will be executed. This could be achieved u sing a new YANG
model.</t> model.</t>
</section>
</section> <section anchor="mg-monitor" numbered="true" toc="default">
<name>Liveness Detection and Monitoring</name>
<section title="Liveness Detection and Monitoring" anchor="mg-monitor"> <t>The extensions defined in this document do not require any additional
liveness detection
<t>The extensions defined in this document do not require any additional liv and monitoring support. See <xref target="RFC5440" format="default"/> an
eness detection d <xref target="RFC5886" format="default"/> for
and monitoring support. See <xref target="RFC5440" /> and <xref target="
RFC5886" /> for
more information.</t> more information.</t>
</section>
</section> <section anchor="mg-verify" numbered="true" toc="default">
<name>Verifying Correct Operation</name>
<section title="Verifying Correct Operation" anchor="mg-verify"> <t>The chief element of operation that needs to be verified (in addition to
the operation
<t>The chief element of operation that needs to be verified (in addition to of the protocol elements as described in <xref target="RFC5440" format="d
the operation efault"/>) is the installation,
of the protocol elements as described in <xref target="RFC5440" />) is th
e installation,
precedence, and correct operation of the Flow Specifications at a PCC.</t > precedence, and correct operation of the Flow Specifications at a PCC.</t >
<t>In addition to the YANG model, for reading Flow Specifications descri
<t>In addition to the YANG model for reading Flow Specifications described i bed in <xref target="mg-model" format="default"/>,
n <xref target="mg-model" />,
tools may be needed to inject Operations and Management (OAM) traffic at the PCC that matches tools may be needed to inject Operations and Management (OAM) traffic at the PCC that matches
specific criteria so that it can be monitored as traveling along the desi red path. Such tools are specific criteria so that it can be monitored while traveling along the d esired path. Such tools are
outside the scope of this document.</t> outside the scope of this document.</t>
</section>
</section> <section anchor="mg-reqs" numbered="true" toc="default">
<name>Requirements for Other Protocols and Functional Components</name>
<section title="Requirements on Other Protocols and Functional Components" anc <t>This document places no requirements on other protocols or components
hor="mg-reqs"> .</t>
</section>
<t>This document places no requirements on other protocols or components.</t <section anchor="mg-impact" numbered="true" toc="default">
> <name>Impact on Network Operation</name>
<t>The use of the features described in this document clearly have an im
</section> portant impact
<section title="Impact on Network Operation" anchor="mg-impact">
<t>The use of the features described in this document clearly have an import
ant impact
on network traffic since they cause traffic to be routed on specific path s in the on network traffic since they cause traffic to be routed on specific path s in the
network. However, in practice, these changes make no direct changes to t he network network. However, in practice, these changes make no direct changes to t he network
operation because traffic is already placed on those paths using some pre -existing operation because traffic is already placed on those paths using some pre -existing
configuration mechanism. Thus, the significant change is the reduction i n mechanisms configuration mechanism. Thus, the significant change is the reduction i n mechanisms
that have to be applied, rather than a change to how the traffic is passe d through that have to be applied rather than a change to how the traffic is passed through
the network.</t> the network.</t>
</section>
</section>
<!--<section title="Other Considerations" anchor="mg-other">
<t>No other manageability considerations are known at this time.</t>
</section>-->
</section> </section>
</middle>
<back>
<displayreference target="I-D.ietf-idr-flowspec-l2vpn" to="BGP-L2VPN"/>
<displayreference target="I-D.gont-numeric-ids-sec-considerations" to="NUMERIC-I
DS-SEC"/>
<displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.ietf-teas-yang-path-computation" to="TEAS-YANG-PAT
H"/>
<section title="Acknowledgements"> <references>
<t>Thanks to Julian Lucek, Sudhir Cheruathur, Olivier Dugeon, Jayant Agarwal, <name>References</name>
Jeffrey Zhang, <references>
Acee Lindem, Vishnu Pavan Beeram, Julien Meuric, Deborah Brungard, Eric Vyn <name>Normative References</name>
cke, Erik Kline, <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Benjamin Kaduk, Martin Duke, Roman Danyliw, and Alvaro Retana for useful di FC.2119.xml"/>
scussions and <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
comments.</t> FC.4364.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5440.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5511.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.8232.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8253.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8281.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8955.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8956.xml"/>
</middle> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4655.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5088.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5089.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5886.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6123.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7399.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8283.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8664.xml"/>
<back> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .gont-numeric-ids-sec-considerations.xml"/>
<references title="Normative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
&RFC2119; .ietf-pce-pcep-yang.xml"/>
&RFC4364;
&RFC4760;
&RFC5440;
&RFC5511;
&RFC8174;
&RFC8231;
&RFC8232;
&RFC8253;
&RFC8281;
<?rfc include='reference.I-D.ietf-idr-rfc5575bis'?>
<?rfc include='reference.I-D.ietf-idr-flow-spec-v6'?>
<?rfc include='reference.I-D.ietf-idr-flowspec-l2vpn'?>
</references>
<references title="Informative References"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
&RFC4655; .ietf-teas-yang-path-computation.xml"/>
&RFC5088;
&RFC5089;
&RFC5886;
&RFC6123;
&RFC6952;
&RFC7399;
&RFC7942;
&RFC8126;
&RFC8283;
&RFC8664;
<?rfc include='reference.I-D.gont-numeric-ids-sec-considerations'?>
<?rfc include='reference.I-D.ietf-pce-pcep-yang'?>
<?rfc include='reference.I-D.ietf-teas-yang-path-computation'?>
</references>
<section title="Contributors" toc="default"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-
<figure title="" align="left" height="" width="" alt="" suppress-title="false" D.ietf-idr-flowspec-l2vpn.xml"/>
>
<artwork>
<![CDATA[
Shankara
Huawei Technologies
Divyashree Techno Park,
Whitefield Bangalore,
Karnataka
560066
India
Email: shankara@huawei.com </references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Julian Lucek"/>, <contact fullname="Sudhir
Cheruathur"/>, <contact fullname="Olivier Dugeon"/>, <contact fullname="Jayant
Agarwal"/>, <contact fullname="Jeffrey Zhang"/>,
<contact fullname="Acee Lindem"/>, <contact fullname="Vishnu Pavan Beeram"/
>, <contact fullname="Julien Meuric"/>, <contact fullname="Deborah Brungard"/>,
<contact fullname="Éric Vyncke"/>, <contact fullname="Erik Kline"/>,
<contact fullname="Benjamin Kaduk"/>, <contact fullname="Martin Duke"/>, <c
ontact fullname="Roman Danyliw"/>, and <contact fullname="Alvaro Retana"/> for u
seful discussions and
comments.</t>
</section>
Qiandeng Liang <section toc="default" numbered="false">
Huawei Technologies <name>Contributors</name>
101 Software Avenue,
Yuhuatai District
Nanjing
210012
China
Email: liangqiandeng@huawei.com <contact fullname="Shankara">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Divyashree Techno Park, Whitefield</street>
<extaddr></extaddr>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560066</code>
<country>India</country>
</postal>
Cyril Margaria <email>shankara@huawei.com</email>
Juniper Networks </address>
200 Somerset Corporate Boulevard, Suite 4001 </contact>
Bridgewater, NJ
08807
USA
Email: cmargaria@juniper.net <contact fullname="Qiandeng Liang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>101 Software Avenue,</street>
<extaddr>Yuhuatai District</extaddr>
<region>Nanjing</region><code>210012</code>
<country>China</country>
</postal>
Colby Barth <email>liangqiandeng@huawei.com</email>
Juniper Networks </address>
200 Somerset Corporate Boulevard, Suite 4001 </contact>
Bridgewater, NJ
08807
USA
Email: cbarth@juniper.net <contact fullname="Cyril Margaria">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>200 Somerset Corporate Boulevard, Suite 4001</street>
<region>Bridgewater, NJ</region><code>08807</code>
<country>USA</country>
</postal>
Xia Chen <email>cmargaria@juniper.net</email>
Huawei Technologies </address>
Huawei Bld., No.156 Beiqing Rd. </contact>
Beijing
100095
China
Email: jescia.chenxia@huawei.com <contact fullname="Colby Barth">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>200 Somerset Corporate Boulevard, Suite 4001</street>
<region>Bridgewater, NJ</region>
<code>08807</code>
<country>USA</country>
</postal>
Shunwan Zhuang <email>cbarth@juniper.net</email>
Huawei Technologies </address>
Huawei Bld., No.156 Beiqing Rd. </contact>
Beijing
100095
China
Email: zhuangshunwan@huawei.com <contact fullname="Xia Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No. 156 Beiqing Rd.</street>
<region>Beijing</region>
<code>100095</code>
<country>China</country>
</postal>
Cheng Li <email>jescia.chenxia@huawei.com</email>
Huawei Technologies </address>
Huawei Campus, No. 156 Beiqing Rd. </contact>
Beijing 100095
China
Email: c.l@huawei.com <contact fullname="Shunwan Zhuang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No. 156 Beiqing Rd.</street>
<region>Beijing</region>
<code>100095</code>
<country>China</country>
</postal>
]]> <email>zhuangshunwan@huawei.com</email>
</artwork> </address>
</figure> </contact>
</section>
</back> <contact fullname="Cheng Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Campus, No. 156 Beiqing Rd.</street>
<region>Beijing</region><code>100095</code>
<country>China</country>
</postal>
<email>c.l@huawei.com</email>
</address>
</contact>
</section>
</back>
</rfc> </rfc>
 End of changes. 190 change blocks. 
1496 lines changed or deleted 1310 lines changed or added

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