rfc9015xml2.original.xml   rfc9015.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!-- updated by Chris 09/15/20 -->
<?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 SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC3022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3022.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4271.xml">
<!ENTITY RFC4272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4272.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4360.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4364.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4760.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5925.xml">
<!ENTITY RFC6146 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6146.xml">
<!ENTITY RFC6296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6296.xml">
<!ENTITY RFC6952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6952.xml">
<!ENTITY RFC7432 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7432.xml">
<!ENTITY RFC7498 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7498.xml">
<!ENTITY RFC7606 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7606.xml">
<!ENTITY RFC7665 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7665.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 RFC8300 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8300.xml">
<!ENTITY RFC8595 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8595.xml">
<!ENTITY RFC8596 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8596.xml">
]>
<rfc category="std" docName="draft-ietf-bess-nsh-bgp-control-plane-18" ipr="trus <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
t200902"> docName="draft-ietf-bess-nsh-bgp-control-plane-18" number="9015"
ipr="trust200902" obsoletes="" updates="" submissionType="IETF"
category="std" consensus="true" xml:lang="en" tocInclude="true"
tocDepth="3" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.1.1 -->
<front> <front>
<title abbrev="BGP for NSH SFC">BGP Control Plane for the Network Service He ader in Service Function Chaining</title> <title abbrev="BGP for NSH SFC">BGP Control Plane for the Network Service He ader in Service Function Chaining</title>
<seriesInfo name="RFC" value="9015"/>
<author fullname="Adrian Farrel" initials="A." surname="Farrel"> <author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<author fullname="John Drake" initials="J." surname="Drake"> <author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>jdrake@juniper.net</email> <email>jdrake@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Eric Rosen" initials="E." surname="Rosen"> <author fullname="Eric Rosen" initials="E." surname="Rosen">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>erosen52@gmail.com</email> <email>erosen52@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Jim Uttaro" initials="J." surname="Uttaro"> <author fullname="Jim Uttaro" initials="J." surname="Uttaro">
<organization>AT&amp;T</organization> <organization>AT&amp;T</organization>
<address> <address>
<email>ju1738@att.com</email> <email>ju1738@att.com</email>
</address> </address>
</author> </author>
<author fullname="Luay Jalil" initials="L" surname="Jalil"> <author fullname="Luay Jalil" initials="L" surname="Jalil">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<email>luay.jalil@verizon.com</email> <email>luay.jalil@verizon.com</email>
</address> </address>
</author> </author>
<date year="2021" month="June" />
<date year="2020" />
<area>Routing</area> <area>Routing</area>
<workgroup>BESS Working Group</workgroup> <workgroup>BESS Working Group</workgroup>
<keyword>Service Function Chaining</keyword> <keyword>Service Function Chaining</keyword>
<keyword>Service Function Chain</keyword> <keyword>Service Function Chain</keyword>
<keyword>Network Service Header</keyword> <keyword>Network Service Header</keyword>
<keyword>Service Function</keyword> <keyword>Service Function</keyword>
<keyword>Service Function Forwarder</keyword> <keyword>Service Function Forwarder</keyword>
<keyword>Service Function Path</keyword> <keyword>Service Function Path</keyword>
<keyword>Service Function Path Route</keyword> <keyword>Service Function Path Route</keyword>
<keyword>Service Function Instance</keyword> <keyword>Service Function Instance</keyword>
skipping to change at line 91 skipping to change at line 60
<keyword>Service Function Chain</keyword> <keyword>Service Function Chain</keyword>
<keyword>Network Service Header</keyword> <keyword>Network Service Header</keyword>
<keyword>Service Function</keyword> <keyword>Service Function</keyword>
<keyword>Service Function Forwarder</keyword> <keyword>Service Function Forwarder</keyword>
<keyword>Service Function Path</keyword> <keyword>Service Function Path</keyword>
<keyword>Service Function Path Route</keyword> <keyword>Service Function Path Route</keyword>
<keyword>Service Function Instance</keyword> <keyword>Service Function Instance</keyword>
<keyword>Service Function Instance Route</keyword> <keyword>Service Function Instance Route</keyword>
<keyword>Service Function Type</keyword> <keyword>Service Function Type</keyword>
<keyword>Control Plane</keyword> <keyword>Control Plane</keyword>
<abstract> <abstract>
<t>This document describes the use of BGP as a control plane for networks that support <t>This document describes the use of BGP as a control plane for networks that support
Service Function Chaining (SFC). The document introduces a new BGP add service function chaining. The document introduces a new BGP address f
ress family amily
called the SFC Address Family Identifier / Subsequent Address Family Id called the "Service Function Chain (SFC) Address Family Identifier / Su
entifier (SFC bsequent Address Family Identifier" (SFC
AFI/SAFI) with two route types. One route type is originated by a node AFI/SAFI) with two Route Types. One Route Type is originated by a node
to advertise to advertise
that it hosts a particular instance of a specified service function. T that it hosts a particular instance of a specified service function. T
his route type his Route Type
also provides "instructions" on how to send a packet to the hosting nod e in a way that also provides "instructions" on how to send a packet to the hosting nod e in a way that
indicates that the service function has to be applied to the packet. T indicates that the service function has to be applied to the packet. T
he other route he other Route
type is used by a Controller to advertise the paths of "chains" of serv Type is used by a controller to advertise the paths of "chains" of serv
ice functions, ice functions
and to give a unique designator to each such path so that they can be u and give a unique designator to each such path so that they can be used
sed in in
conjunction with the Network Service Header defined in RFC 8300.</t> conjunction with the Network Service Header (NSH) defined in RFC 8300.<
/t>
<t>This document adopts the SFC architecture described in RFC 7665.</t> <t>This document adopts the service function chaining architecture describ
ed in RFC 7665.</t>
</abstract> </abstract>
</front>
</front> <middle>
<section anchor="introduction" numbered="true" toc="default">
<middle> <name>Introduction</name>
<t>As described in <xref target="RFC7498" format="default"/>, the delivery
<section anchor="introduction" title="Introduction"> of end-to-end services can
require a packet to pass through a series of Service Functions (SFs) --
<t>As described in <xref target="RFC7498" />, the delivery of end-to-end ser e.g., WAN and
vices can
require a packet to pass through a series of Service Functions (SFs) (e.g
., WAN and
application accelerators, Deep Packet Inspection (DPI) engines, firewalls , TCP application accelerators, Deep Packet Inspection (DPI) engines, firewalls , TCP
optimizers, and server load balancers) in a specified order: this is term optimizers, and server load balancers -- in a specified order; this is te
ed rmed
"Service Function Chaining" (SFC). There are a number of issues associat "service function chaining". There are a number of issues associated wit
ed with h
deploying and maintaining service function chaining in production network s, which are deploying and maintaining service function chaining in production network s, which are
described below.</t> described below.</t>
<t>Historically, if a packet needed to travel through a particular service
<t>Historically, if a packet needed to travel through a particular service c chain, the
hain, the
nodes hosting the service functions of that chain were placed in the netw ork topology nodes hosting the service functions of that chain were placed in the netw ork topology
in such a way that the packet could not reach its ultimate destination wi thout first in such a way that the packet could not reach its ultimate destination wi thout first
passing through all the service functions in the proper order. This need to place the passing through all the service functions in the proper order. This need to place the
service functions at particular topological locations limited the ability to adapt a service functions at particular topological locations limited the ability to adapt a
service function chain to changes in network topology (e.g., link or node failures), service function chain to changes in network topology (e.g., link or node failures),
network utilization, or offered service load. These topological restrict ions on where network utilization, or offered service load. These topological restrict ions on where
the service functions can be placed raised the following issues: the service functions could be placed raised the following issues:
<list style="numbers">
<t>The process of configuring or modifying a service function chain is
operationally
complex and may require changes to the network topology.</t>
<t>Alternate or redundant service functions may need to be co-located w
ith the
primary service functions.</t>
<t>When there is more than one path between source and destination, for </t>
warding may be <ol spacing="normal" type="1"><li>The process of configuring or modifying
asymmetric and it may be difficult to support bidirectional service a service function chain is operationally
function chains complex and may require changes to the network topology.</li>
<li>Alternate or redundant service functions may need to be co-located w
ith the
primary service functions.</li>
<li>When there is more than one path between source and destination, for
warding may be
asymmetric, and it may be difficult to support bidirectional service
function chains
using simple routing methodologies and protocols without adding mech anisms for traffic using simple routing methodologies and protocols without adding mech anisms for traffic
steering or traffic engineering.</t> steering or traffic engineering.</li>
</list></t> </ol>
<t>In order to address these issues, the service function chaining archite
<t>In order to address these issues, the SFC architecture describes Service cture describes service function chains
Function Chains
that are built in their own overlay network (the service function overlay network), that are built in their own overlay network (the service function overlay network),
coexisting with other overlay networks, over a common underlay network coexisting with other overlay networks, over a common underlay network
<xref target="RFC7665" />. A Service Function Chain is a sequence of Ser vice Functions <xref target="RFC7665" format="default"/>. A service function chain is a sequence of service functions
through which packet flows that satisfy specified criteria will pass.</t> through which packet flows that satisfy specified criteria will pass.</t>
<t>This document describes the use of BGP as a control plane for networks
<t>This document describes the use of BGP as a control plane for networks th that support service function chaining. The document introduces a new BGP addre
at support ss family
Service Function Chaining (SFC). The document introduces a new BGP addre called the "Service Function Chain (SFC) Address Family Identifier / Subs
ss family equent Address Family Identifier"
called the SFC Address Family Identifier / Subsequent Address Family Iden (SFC AFI/SAFI) with two Route Types. One Route Type is originated by a
tifier
(AFI/SAFI) with two route types. One route type is originated by a
node to advertise that it hosts a particular instance of a specified serv ice function. node to advertise that it hosts a particular instance of a specified serv ice function.
This route type also provides "instructions" on how to send a packet to t he hosting This Route Type also provides "instructions" on how to send a packet to t he hosting
node in a way that indicates that the service function has to be applied to the packet. node in a way that indicates that the service function has to be applied to the packet.
The other route type is used by a Controller (a centralized network compo The other Route Type is used by a controller (a centralized network compo
nent responsible nent responsible
for planning and coordinating Service Function Chaining within the networ for planning and coordinating service function chaining within the networ
k) to advertise k) to advertise
the paths of "chains" of service functions, and to give a unique designat the paths of "chains" of service functions and give a unique designator t
or to each such o each such
path so that they can be used in conjunction with the Network Service Hea path so that they can be used in conjunction with the Network Service Hea
der der (NSH)
<xref target="RFC8300"/>.</t> <xref target="RFC8300" format="default"/>.</t>
<t>This document adopts the service function chaining architecture describ
<t>This document adopts the SFC architecture described in <xref target="RFC7 ed in <xref target="RFC7665" format="default"/>.</t>
665"/>.</t> <section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMEND
"OPTIONAL" in this document are to be interpreted as described in BCP ED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only whe "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as des
n, cribed in BCP
14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" for
mat="default"/> when, and only when,
they appear in all capitals, as shown here.</t> they appear in all capitals, as shown here.</t>
</section> </section>
<section anchor="terms" numbered="true" toc="default">
<section anchor="terms" title="Terminology"> <name>Terminology</name>
<t>This document uses the following terms from <xref target="RFC7665"/>: <t>This document uses the following terms from <xref target="RFC7665" fo
<list style="symbols"> rmat="default"/>:
<t>Bidirectional Service Function Chain</t> </t>
<t>Classifier</t> <ul spacing="normal">
<t>Service Function (SF)</t> <li>Bidirectional Service Function Chain</li>
<t>Service Function Chain (SFC)</t> <li>Classifier</li>
<t>Service Function Forwarder (SFF)</t> <li>Service Function (SF)</li>
<t>Service Function Instance (SFI)</t> <li>Service Function Chain (SFC)</li>
<t>Service Function Path (SFP)</t> <li>Service Function Forwarder (SFF)</li>
<t>SFC branching</t> <li>Service Function Instance (SFI)</li>
</list></t> <li>Service Function Path (SFP)</li>
<li>SFC branching</li>
<t>Additionally, this document uses the following terms from <xref target </ul>
="RFC8300"/>: <t>Additionally, this document uses the following terms from <xref targe
<list style="symbols"> t="RFC8300" format="default"/>:
<t>Network Service Header (NSH)</t> </t>
<t>Service Index (SI)</t> <ul spacing="normal">
<t>Service Path Identifier (SPI)</t> <li>Network Service Header (NSH)</li>
</list></t> <li>Service Index (SI)</li>
<li>Service Path Identifier (SPI)</li>
<t>This document introduces the following terms: </ul>
<list style="symbols"> <t>This document introduces the following terms:
<t>Service Function Instance Route (SFIR). A new BGP Route Type ad </t>
vertised by the <dl>
<dt>Service Function Instance Route (SFIR):</dt><dd>A new BGP Route Ty
pe advertised by the
node that hosts an SFI to describe the SFI and to announce the w ay to forward a node that hosts an SFI to describe the SFI and to announce the w ay to forward a
packet to the node through the underlay network.</t> packet to the node through the underlay network.</dd>
<dt>Service Function Overlay Network:</dt><dd>The logical network comp
<t>Service Function Overlay Network. The logical network comprised rised of classifiers,
of Classifiers,
SFFs, and SFIs that are connected by paths or tunnels through un derlay transport SFFs, and SFIs that are connected by paths or tunnels through un derlay transport
networks.</t> networks.</dd>
<dt>Service Function Path Route (SFPR):</dt><dd>A new BGP Route Type o
<t>Service Function Path Route (SFPR). A new BGP Route Type origin riginated by controllers to
ated by Controllers to advertise the details of each SFP.</dd>
advertise the details of each SFP.</t> <dt>Service Function Type (SFT):</dt><dd>An indication of the function
and features of an SFI.</dd>
<t>Service Function Type (SFT). An indication of the function and </dl>
features of an SFI.</t> </section>
</list></t>
</section> </section>
<section anchor="overview" numbered="true" toc="default">
</section> <name>Overview</name>
<t>This section provides an overview of service function chaining in gener
<section anchor="overview" title="Overview"> al and the control
<t>This section provides an overview of Service Function Chaining in general
, and the control
plane defined in this document. After reading this section, readers may find it helpful to plane defined in this document. After reading this section, readers may find it helpful to
look through <xref target="example" /> for some simple worked examples.</ look through <xref target="example" format="default"/> for some simple wo
t> rked examples.</t>
<section anchor="funcover" numbered="true" toc="default">
<section anchor="funcover" title="Overview of Service Function Chaining"> <name>Overview of Service Function Chaining</name>
<t>In <xref target="RFC8300" format="default"/>, a Service Function Chai
<t>In <xref target="RFC8300"/> a Service Function Chain (SFC) is an ordere n (SFC) is an ordered list of
d list of
Service Functions (SFs). A Service Function Path (SFP) is an indicatio n of which instances Service Functions (SFs). A Service Function Path (SFP) is an indicatio n of which instances
of SFs are acceptable to be traversed in an instantiation of an SFC in a service function of SFs are acceptable to be traversed in an instantiation of an SFC in a service function
overlay network. The Service Path Identifier (SPI) is a 24-bit number that identifies overlay network. The Service Path Identifier (SPI) is a 24-bit number that identifies
a specific SFP, and a Service Index (SI) is an 8-bit number that identi fies a specific point a specific SFP, and a Service Index (SI) is an 8-bit number that identi fies a specific point
in that path. In the context of a particular SFP (identified by an SPI ), an SI represents a in that path. In the context of a particular SFP (identified by an SPI ), an SI represents a
particular Service Function, and indicates the order of that SF in the particular service function and indicates the order of that SF in the S
SFP.</t> FP.</t>
<t>Within the context of a specific SFP, an SI references a set of one o
<t>Within the context of a specific SFP, an SI references a set of one or r more SFs. Each of those SFs
more SFs. Each of those SFs may be supported by one or more Service Function Instances (SFIs). Thu
may be supported by one or more Service Function Instances (SFIs). Thu s, an SI may represent a choice
s an SI may represent a choice of SFIs of one or more service function types. By deploying multiple S
of SFIs of one or more Service Function Types. By deploying multiple S FIs for a single SF, one
FIs for a single SF, one
can provide load balancing and redundancy.</t> can provide load balancing and redundancy.</t>
<t>A special functional element, called a "classifier", is located at ea
<t>A special functional element, called a Classifier, is located at each i ch ingress point to a service
ngress point to a service function overlay network. It assigns the packets of a given packet flo
function overlay network. It assigns the packets of a given packet flo w to a specific SFP. This may be done by comparing specific fields in a packet'
w to a specific Service s header with
Function Path. This may be done by comparing specific fields in a pack local policy, which may be customer/network/service specific. The clas
et&apos;s header with sifier picks an SFP and
local policy, which may be customer/network/service specific. The Clas sets the SPI accordingly; it then sets the SI to the value of the SI fo
sifier picks an SFP and r the first hop in the
sets the SPI accordingly, it then sets the SI to the value of the SI fo SFP, and then prepends a Network Service Header (NSH) <xref target="RFC
r the first hop in the 8300" format="default"/>
SFP, and then prepends a Network Services Header (NSH) <xref target="RF containing the assigned SPI/SI to that packet. Note that the classifie
C8300" /> r and the node that
containing the assigned SPI/SI to that packet. Note that the Classifie hosts the first SF in an SFP need not be located at the same
r and the node that
hosts the first Service Function in a Service Function Path need not be
located at the same
point in the service function overlay network.</t> point in the service function overlay network.</t>
<t>Note that the presence of the NSH can make it difficult for nodes in
<t>Note that the presence of the NSH can make it difficult for nodes in th the underlay network
e underlay network to locate the fields in the original packet that would normally be
to locate the fields in the original packet that would normally be used used to constrain equal-cost multipath (ECMP) forwarding. Therefore,
to constrain equal it is recommended that the node prepending the
cost multipath (ECMP) forwarding. Therefore, it is recommended that th
e node prepending the
NSH also provide some form of entropy indicator that can be used in the underlay network. How NSH also provide some form of entropy indicator that can be used in the underlay network. How
this indicator is generated and supplied, and how an SFF generates a ne w entropy indicator this indicator is generated and supplied, and how an SFF generates a ne w entropy indicator
when it forwards a packet to the next SFF, are out of scope of this doc when it forwards a packet to the next SFF, are out of the scope of this
ument.</t> document.</t>
<t>The Service Function Forwarder (SFF) receives a packet from the previ
<t>The Service Function Forwarder (SFF) receives a packet from the previou ous node in an SFP, removes the packet's link layer or tunnel encapsulation, and
s node in a Service hands the
Function Path, removes the packet&apos;s link layer or tunnel encapsula packet and the NSH to the SFI for processing. The SFI has no knowledge
tion and hands the
packet and the NSH to the Service Function Instance for processing. Th
e SFI has no knowledge
of the SFP.</t> of the SFP.</t>
<t>When the SFF receives the packet and the NSH back from the SFI, it mu
<t>When the SFF receives the packet and the NSH back from the SFI it must st select the next SFI
select the next SFI
along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs along the path using the SPI and SI in the NSH and potentially choosing between multiple SFIs
(possibly of different Service Function Types) as described in <xref ta (possibly of different SFTs), as described in <xref target="selection"
rget="selection" />. In format="default"/>. In
the normal case the SPI remains unchanged and the SI will have been dec the normal case, the SPI remains unchanged, and the SI will have been d
remented to indicate the ecremented to indicate the
next SF along the path. But other possibilities exist if the SF makes other changes to the NSH next SF along the path. But other possibilities exist if the SF makes other changes to the NSH
through a process of re-classification: through a process of reclassification:
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>The SI in the NSH may indicate: <t>The SI in the NSH may indicate:
<list style="symbols"> </t>
<t>A previous SF in the path: known as "looping" (see <xref ta <ul spacing="normal">
rget="looping"/>).</t> <li>A previous SF in the path; this is known as "looping" (see
<t>An SF further down the path: known as "jumping" (see also < <xref target="looping" format="default"/>).</li>
xref target="looping"/>).</t> <li>An SF further down the path; this is known as "jumping"
</list></t> (again see <xref target="looping" format="default"/>).</li>
<t>The SPI and the SI may point to an SF on a different SFP: known a </ul>
s "branching" (see also </li>
<xref target="looping"/>).</t> <li>The SPI and the SI may point to an SF on a different SFP; this is
</list></t> known as "branching" (see
<xref target="looping" format="default"/>).</li>
<t>Such modifications are limited to within the same service function over </ul>
lay network. That is, an <t>Such modifications are limited to within the same service function ov
erlay network. That is, an
SPI is known within the scope of service function overlay network. Fur thermore, the new SI value SPI is known within the scope of service function overlay network. Fur thermore, the new SI value
is interpreted in the context of the SFP identified by the SPI.</t> is interpreted in the context of the SFP identified by the SPI.</t>
<t>As described in <xref target="RFC8300" format="default"/>, an SPI tha
<t>As described in <xref target="RFC8300"/>, an unknown or invalid SPI is t is unknown or not valid is treated as an error, and
treated as an error and the SFF drops the packet; such errors should be logged, and such logs a
the SFF drops the packet: such errors should be logged, and such logs a re subject to rate limits.</t>
re subject to rate limits.</t> <t>Also, as described in <xref target="RFC8300" format="default"/>, an S
FF receiving an SI that is unknown in the
<t>Also, as described in <xref target="RFC8300" />, an SFF receiving an SI
that is unknown in the
context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by context of the SPI can reduce the value to the next meaningful SI value in the SFP indicated by
the SPI. If no such value exists or if the SFF does not support reduci the SPI. If no such value exists, or if the SFF does not support reduc
ng the SI, the SFF drops the ing the SI, the SFF drops the
packet and should log the event: such logs are also subject to rate lim packet and should log the event; such logs are also subject to rate lim
its.</t> its.</t>
<t>The SFF then selects an SFI that provides the SF denoted by the SPI/S
<t>The SFF then selects an SFI that provides the SF denoted by the SPI/SI, I and forwards the packet
and forwards the packet
to the SFF that supports that SFI.</t> to the SFF that supports that SFI.</t>
<t><xref target="RFC8300" format="default"/> makes it clear that the int
<t><xref target="RFC8300" /> makes it clear that the intended scope is for ended scope is for use within a single
use within a single provider's operational domain.</t>
provider&apos;s operational domain.</t> <t>This document adopts the service function chaining architecture descr
ibed in <xref target="RFC7665" format="default"/> and adds a
<t>This document adopts the SFC architecture described in <xref target="RF control plane to support the functions, as described in <xref target="c
C7665" /> and adds a trlover" format="default"/>. An essential
control plane to support the functions as described in <xref target="ct component of this solution is the controller. This is a network compon
rlover" />. An essential ent responsible for
component of this solution is the Controller. This is a network compon
ent responsible for
planning SFPs within the network. It gathers information about the ava ilability of SFIs and SFFs, planning SFPs within the network. It gathers information about the ava ilability of SFIs and SFFs,
instructs the control plane about the SFPs to be programmed, and instru cts the Classifiers how instructs the control plane about the SFPs to be programmed, and instru cts the classifiers how
to assign traffic flows to individual SFPs.</t> to assign traffic flows to individual SFPs.</t>
</section>
</section> <section anchor="ctrlover" numbered="true" toc="default">
<name>Control Plane Overview</name>
<section anchor="ctrlover" title="Control Plane Overview"> <t>To accomplish the function described in <xref target="funcover" forma
t="default"/>, this document
<t>To accomplish the function described in <xref target="funcover" />, thi introduces the Service Function Type (SFT), which is the category of SF
s document that is supported
introduces the Service Function Type (SFT) that is the category of SF t by an SFF (such as "firewall"). An IANA registry of service function t
hat is supported ypes is introduced
by an SFF (such as "firewall"). An IANA registry of Service Function T in <xref target="SFTreg" format="default"/> and is consistent with type
ypes is introduced s used in other work, such as
in <xref target="SFTreg" /> and is consistent with types used in other <xref target="I-D.dawra-idr-bgp-ls-sr-service-segments" format="default
work such as "/>. An SFF may support SFs of
<xref target="I-D.dawra-idr-bgp-ls-sr-service-segments" />. An SFF may multiple different SFTs, and it may support multiple SFIs of each SF.</
support SFs of t>
multiple different SFTs, and may support multiple SFIs of each SF.</t> <t>The registry of SFT values (see <xref target="SFTreg"/>) is split int
o three ranges with assignment
<t>The registry of SFT values (see Section 10.5) is split into three range policies per <xref target="RFC8126" format="default"/>:
s with assignment </t>
policies per <xref target="RFC8126" />: <ul spacing="normal">
<list style="symbols"> <li>The special-purpose SFT values range is assigned through Standards
Action.
<t>The Special Purpose SFT values range is assigned through Standard
s Action.
Values in that range are used for special SFC operations and do n ot apply to Values in that range are used for special SFC operations and do n ot apply to
the types of SF that may form part of the SFP.</t> the types of SF that may form part of the SFP.</li>
<t>The First Come First Served range tracks assignments of STF value s made by any <li>The First Come First Served range tracks assignments of SFT values made by any
party that defines an SF type. Reference through an Internet-Draf t is desirable, party that defines an SF type. Reference through an Internet-Draf t is desirable,
but not required.</t> but not required.</li>
<li>The Private Use range is not tracked by IANA and is primarily inte
<t>The Private Use range is not tracked by IANA and is primarily int nded for use
ended for use
in private networks where the meaning of the SFT values is locall y tracked and in private networks where the meaning of the SFT values is locall y tracked and
under the control of a local administrator.</t> under the control of a local administrator.</li>
</ul>
</list></t> <t>It is envisaged that the majority of SFT values used will be assigned
from the First Come
<t>It is envisaged that the majority of SFT values used will be assigned f First Served space in the registry. This will ensure interoperability,
rom the First Come especially in
First Served space in the registry. This will ensure interoperability situations where software and hardware from different vendors are deplo
especially in yed in the same
situations where software and hardware from different vendors is deploy
ed in the same
networks, or when networks are merged. However, operators of private ne tworks may choose networks, or when networks are merged. However, operators of private ne tworks may choose
to develop their own SFs and manage the configuration and operation of their network through to develop their own SFs and manage the configuration and operation of their network through
their own list of SFT values.</t> their own list of SFT values.</t>
<t>This document also introduces a new BGP AFI/SAFI (values 31 and 9, re
spectively) for "SFC Routes".
Two SFC Route Types are defined by this document: the Service Function
Instance Route (SFIR) and
the Service Function Path Route (SFPR). As detailed in <xref target="s
fcBGPRoutes" format="default"/>, the Route
Type is indicated by a subfield in the Network Layer Reachability Infor
mation (NLRI).
<t>This document also introduces a new BGP AFI/SAFI (values to be assigned </t>
by IANA) for "SFC Routes". <ul spacing="normal">
Two SFC Route Types are defined by this document: the Service Function <li>The SFIR is advertised by the node that provides access to the ser
Instance Route (SFIR), and vice function instance
the Service Function Path Route (SFPR). As detailed in <xref target="s (i.e., the SFF). The SFIR describes a particular instance of a p
fcBGPRoutes" />, the route articular SF
type is indicated by a sub-field in the Network Layer Reachability Info (i.e., an SFI) and the way to forward a packet to it through
rmation (NLRI). the underlay network, i.e., IP
address and encapsulation information.</li>
<list style="symbols"> <li>
<t>The SFPRs are originated by controllers. One SFPR is originated
<t>The SFIR is advertised by the node that provides access to the se for each SFP. The SFPR specifies:
rvice function instance </t>
(i.e., the SFF). The SFIR describes a particular instance of a p <ol spacing="normal" type="A"><li>the SPI of the path,</li>
articular Service Function <li>the sequence of SFTs and/or SFIs of which the path consists, a
(i.e., an SFI) and the way to forward a packet to it through the nd</li>
underlay network, i.e., IP <li>for each such SFT or SFI, the SI that represents it in the ide
address and encapsulation information.</t> ntified path.</li>
</ol>
<t>The SFPRs are originated by Controllers. One SFPR is originated </li>
for each Service </ul>
Function Path. The SFPR specifies: <t>This approach assumes that there is an underlay network that provides
<list style="letters"> connectivity between
<t>the SPI of the path</t> SFFs and controllers and that the SFFs are grouped to form one or more
<t>the sequence of SFTs and/or SFIs of which the path consists service function
</t> overlay networks through which SFPs are built. We assume that the cont
<t>for each such SFT or SFI, the SI that represents it in the rollers have BGP
identified path.</t> connectivity to all SFFs and all classifiers within each service functi
</list></t> on overlay network.</t>
<t>When choosing the next SFI in a path, the SFF uses the SPI and SI as
</list></t> well as the SFT to choose
among the SFIs, applying, for example, a load-balancing algorithm or di
<t>This approach assumes that there is an underlay network that provides c rect knowledge of the
onnectivity between underlay network topology, as described in <xref target="mode" format="
SFFs and Controllers, and that the SFFs are grouped to form one or more default"/>.</t>
service function <t>The SFF then encapsulates the packet using the encapsulation specifie
overlay networks through which SFPs are built. We assume that the Cont d by the SFIR of the
rollers have BGP selected SFI and forwards the packet. See <xref target="SFCarch" forma
connectivity to all SFFs and all Classifiers within each service functi t="default"/>.</t>
on overlay network.</t> <t>Thus, the SFF can be seen as a portal in the underlay network through
which a particular SFI
<t>When choosing the next SFI in a path, the SFF uses the SPI and SI as we
ll as the SFT to choose
among the SFIs, applying, for example, a load balancing algorithm or di
rect knowledge of the
underlay network topology as described in <xref target="mode" />.</t>
<t>The SFF then encapsulates the packet using the encapsulation specified
by the SFIR of the
selected SFI and forwards the packet. See <xref target="SFCarch" />.</
t>
<t>Thus the SFF can be seen as a portal in the underlay network through wh
ich a particular SFI
is reached.</t> is reached.</t>
<t><xref target="SFCarch" format="default"/> shows a reference model for
<t><xref target="SFCarch"/> shows a reference model for the SFC architectu the service function chaining architecture. There are four SFFs
re. There are four SFFs
(SFF-1 through SFF-4) connected by tunnels across the underlay network. Packets arrive at (SFF-1 through SFF-4) connected by tunnels across the underlay network. Packets arrive at
a Classifier and are channeled along SFPs to destinations reachable thr a classifier and are channeled along SFPs to destinations reachable thr
ough SFF-4.</t> ough SFF-4.</t>
<t>SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SF
<t>SFF-1 and SFF-4 each have one instance of one SF attached (SFa and SFe) e). SFF-2 has two types
. SFF-2 has two types of SF attached: one instance of one (SFc) and three instances of the ot
of SF attached: there is one instance of one (SFc), and three instances her (SFb).
of the other (SFb). SFF-3 has just one instance of an SF (SFd), but in this case, the type
SFF-3 has just one instance of an SF (SFd), but it in this case the typ of SFd is the same
e of SFd is the same
type as SFb (SFTx).</t> type as SFb (SFTx).</t>
<t>This figure demonstrates how load balancing can be achieved by creati
<t>This figure demonstrates how load balancing can be achieved by creating ng several SFPs that satisfy
several SFPs that satisfy
the same SFC. Suppose an SFC needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs the same SFC. Suppose an SFC needs to include SFa, an SF of type SFTx, and SFc. A number of SFPs
can be constructed using any instance of SFb or using SFd. Load balanc ing may be applied at two can be constructed using any instance of SFb or using SFd. Load balanc ing may be applied at two
places: places:
<list style="symbols"> </t>
<t>The Classifier may distribute different flows onto different SFPs <ul spacing="normal">
to share the load in the <li>The classifier may distribute different flows onto different SFPs
network and across SFIs.</t> to share the load in the
<t>SFF-2 may distribute different flows (on the same SFP) to differen network and across SFIs.</li>
t instances of SFb to share <li>SFF-2 may distribute different flows (on the same SFP) to differen
the processing load.</t> t instances of SFb to share
</list></t> the processing load.</li>
</ul>
<t>Note that, for convenience and clarity, <xref target="SFCarch" /> shows <t>Note that, for convenience and clarity, <xref target="SFCarch" format
only a few tunnels between ="default"/> shows only a few tunnels between
SFFs. There could be a full mesh of such tunnels, or more likely, a se lection of tunnels connecting SFFs. There could be a full mesh of such tunnels, or more likely, a se lection of tunnels connecting
key SFFs to enable the construction of SFPs and to balance load and tra key SFFs to enable the construction of SFPs and balance load and traffi
ffic in the network. Further, c in the network. Further,
the figure does not show any controllers: these would each have BGP con the figure does not show any controllers; these would each have BGP con
nectivity to the Classifier and nectivity to the classifier and
all of the SFFs.</t> all of the SFFs.</t>
<figure anchor="SFCarch">
<figure anchor="SFCarch" title="The SFC Architecture Reference Model"> <name>The Service Function Chaining Architecture Reference Model</name
<artwork> >
<![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
Packets Packets
| | | | | |
------------ ------------
| | | |
| Classifier | | Classifier |
| | | |
------+----- ------+-----
| |
---+--- --------- ------- ---+--- --------- -------
| | Tunnel | | | | | | Tunnel | | | |
| SFF-1 |===============| SFF-2 |=========| SFF-4 | | SFF-1 |===============| SFF-2 |=========| SFF-4 |
skipping to change at line 444 skipping to change at line 373
| | | | | | | | | | | |
| |======| SFF-3 |====================| | | |======| SFF-3 |====================| |
---+--- | | ---+--- ---+--- | | ---+---
| ------- | | ------- |
....|.... ....|.... ....|.... ....|....
: | SFa: : | SFe: : | SFa: : | SFe:
: --+-- : : --+-- : : --+-- : : --+-- :
: | SFI | : : | SFI | : : | SFI | : : | SFI | :
: ----- : : ----- : : ----- : : ----- :
......... ......... ......... .........
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>As previously noted, <xref target="RFC8300" format="default"/> makes
it clear that the mechanisms it defines
<t>As previously noted, <xref target="RFC8300" /> makes it clear that the are intended for use within a single provider's operational domain. Th
mechanisms it defines is reduces the
are intended for use within a single provider&apos;s operational domain requirements on the control plane function.</t>
. This reduces the
requirements on the control plane function.</t>
<t><xref target="RFC7665" /> sets out the functions provided by a control <t><xref target="RFC7665" section="5.2" sectionFormat="of"/> sets out th
plane for an SFC network e functions provided by a control plane for a service function chaining network.
in Section 5.2. The functions are broken down into six items the first The functions are broken down into six items, the first four of which
four of which are are
completely covered by the mechanisms described in this document: completely covered by the mechanisms described in this document:
<list style="numbers"> </t>
<t>Visibility of all SFs and the SFFs through which they are reached. <ol spacing="normal" type="1"><li>Visibility of all SFs and the SFFs thr
</t> ough which they are reached.</li>
<t>Computation of SFPs and programming into the network.</t> <li>Computation of SFPs and programming into the network.</li>
<t>Selection of SFIs explicitly in the SFP or dynamically within the <li>Selection of SFIs explicitly in the SFP or dynamically within the
network.</t> network.</li>
<t>Programming of SFFs with forwarding path information.</t> <li>Programming of SFFs with forwarding path information.</li>
</list></t> </ol>
<t>The fifth and sixth items in the list in RFC 7665 concern the use of
<t>The fifth and six items in the list in RFC 7665 concern the use of meta metadata. These are
data. These are more peripheral to the control plane mechanisms defined in this documen
more peripheral to the control plane mechanisms defined in this documen t but are discussed
t, but are discussed in <xref target="classy" format="default"/>.</t>
in <xref target="classy" />.</t> </section>
</section> </section>
<section anchor="sfcBGPRoutes" numbered="true" toc="default">
</section> <name>BGP SFC Routes</name>
<t>This document defines a new AFI/SAFI for BGP, known as "SFC", with an N
<section anchor="sfcBGPRoutes" title="BGP SFC Routes"> LRI that is described
<t>This document defines a new AFI/SAFI for BGP, known as "SFC", with an NLR
I that is described
in this section.</t> in this section.</t>
<t>The format of the SFC NLRI is shown in <xref target="SFCnlriFig" format
="default"/>.</t>
<figure anchor="SFCnlriFig">
<name>The Format of the SFC NLRI</name>
<t>The format of the SFC NLRI is shown in <xref target="SFCnlriFig" />.</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="SFCnlriFig" title="The Format of the SFC NLRI">
<artwork>
<![CDATA[
+---------------------------------------+ +---------------------------------------+
| Route Type (2 octets) | | Route Type (2 octets) |
+---------------------------------------+ +---------------------------------------+
| Length (2 octets) | | Length (2 octets) |
+---------------------------------------+ +---------------------------------------+
| Route Type specific (variable) | | Route Type specific (variable) |
+---------------------------------------+ +---------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The "Route Type" field determines the encoding of the rest of the Route
Type specific SFC NLRI.</t>
<t>The Route Type field determines the encoding of the rest of the route typ <t>The "Length" field indicates the length, in octets, of the "Route Type
e specific SFC NLRI.</t> specific" field of the SFC
<t>The Length field indicates the length in octets of the route type specifi
c field of the SFC
NLRI.</t> NLRI.</t>
<t>This document defines the following Route Types:
<t>This document defines the following Route Types: </t>
<list style="numbers"> <ol spacing="normal" type="1"><li>Service Function Instance Route (SFIR)</
<t>Service Function Instance Route (SFIR)</t> li>
<t>Service Function Path Route (SFPR)</t> <li>Service Function Path Route (SFPR)</li>
</list></t> </ol>
<t>An SFIR is used to identify an SFI. An SFPR defines a sequence of SFs
<t>A Service Function Instance Route (SFIR) is used to identify an SFI. A S (each of which has at least one instance advertised in
ervice Function Path Route
(SFPR) defines a sequence of Service Functions (each of which has at leas
t one instance advertised in
an SFIR) that form an SFP.</t> an SFIR) that form an SFP.</t>
<t>The detailed encoding and procedures for these Route Types are describe
<t>The detailed encoding and procedures for these Route Types are described d in subsequent sections.</t>
in subsequent sections.</t> <t>The SFC NLRI is carried in BGP <xref target="RFC4271"
format="default"/> using BGP Multiprotocol Extensions
<t>The SFC NLRI is carried in BGP <xref target="RFC4271" /> using BGP Multip <xref target="RFC4760" format="default"/> with an Address Family Identifi
rotocol Extensions er (AFI) of 31 and a Subsequent Address
<xref target="RFC4760" /> with an Address Family Identifier (AFI) of TBD1 Family Identifier (SAFI) of 9. The "NLRI" field in the MP_REACH_NLRI/MP_
and a Subsequent Address UNREACH_NLRI attribute
Family Identifier (SAFI) of TBD2. The NLRI field in the MP_REACH_NLRI/MP
_UNREACH_NLRI attribute
contains the SFC NLRI, encoded as specified above.</t> contains the SFC NLRI, encoded as specified above.</t>
<t>In order for two BGP speakers to exchange SFC NLRIs, they
<t>In order for two BGP speakers to exchange SFC NLRIs, they MUST use BGP Ca <bcp14>MUST</bcp14> use BGP capabilities advertisements
pabilities Advertisements
to ensure that they both are capable of properly processing such NLRIs. This is done as specified to ensure that they both are capable of properly processing such NLRIs. This is done as specified
in <xref target="RFC4760" />, by using capability code 1 (Multiprotocol B in <xref target="RFC4760" format="default"/>, by using capability code
GP) with an AFI of TBD1 and 1 (Multiprotocol BGP) with an AFI of 31 and
a SAFI of TBD2.</t> a SAFI of 9.</t>
<t>The "nexthop" field of the MP_REACH_NLRI attribute of the SFC NLRI <bcp
<t>The nexthop field of the MP_REACH_NLRI attribute of the SFC NLRI MUST be 14>MUST</bcp14> be set to a loopback address of
set to a loopback address of
the advertising SFF.</t> the advertising SFF.</t>
<section anchor="sfiRoutes" numbered="true" toc="default">
<section anchor="sfiRoutes" title="Service Function Instance Route (SFIR)"> <name>Service Function Instance Route (SFIR)</name>
<t><xref target="sfiRouteFig" format="default"/> shows the Route Type sp
<t><xref target="sfiRouteFig" /> shows the Route Type specific NLRI of th ecific NLRI of the SFIR.</t>
e SFIR.</t> <figure anchor="sfiRouteFig">
<name>SFIR Route Type Specific NLRI</name>
<figure anchor="sfiRouteFig" title="SFIR Route Type specific NLRI"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+--------------------------------------------+ +--------------------------------------------+
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="RFC4364" format="default"/> defines a Route
Distinguisher (RD) as consisting of a two-byte "Type" field
<t><xref target="RFC4364" /> defines a Route Distinguisher (RD) to consis and a six-byte "Value" field, and it defines RD types 0, 1, and 2. In
t of a two byte Type field this specification, the RD
and a six byte Value field and it defines RD types 0, 1, and 2. In th (used for the SFIR) <bcp14>MUST</bcp14> be of type 0, 1, or 2.</t>
is specification, the RD <t>If two SFIRs are originated from different administrative domains (wi
(used for the SFIR) MUST be of type 0, 1, or 2.</t> thin the same
provider's operational domain), they <bcp14>MUST</bcp14> have differen
<t>If two SFIRs are originated from different administrative domains (wit t RDs. In particular, SFIRs from
hin the same different VPNs (for different service function overlay networks) <bcp1
provier&apos;s operational domain), they MUST have different RDs. In 4>MUST</bcp14> have different RDs, and
particular, SFIRs from those RDs <bcp14>MUST</bcp14> be different from any non-VPN SFIRs.</t>
different VPNs (for different service function overlay networks) MUST <t>The SFT identifies the functions/features an
have different RDs, and SF can offer, e.g.,
those RDs MUST be different from any non-VPN SFIRs.</t> classifier, firewall, load balancer. There may be several SFIs that c
an perform a given
<t>The Service Function Type identifies the functions/features a service service function. Each node hosting an SFI <bcp14>MUST</bcp14> origin
function can offer, e.g., ate an SFIR for each type of SF that it
Classifier, firewall, load balancer. There may be several SFIs that c hosts (as indicated by the SFT value), and it <bcp14>MAY</bcp14> adver
an perform a given tise an SFIR for each instance of each type of SF. A minimal
Service Function. Each node hosting an SFI MUST originate an SFIR for
each type of SF that it
hosts (as indicated by the SFT value), and it MAY advertise an SFIR fo
r each instance of each type of SF. The minimal
advertisement allows construction of valid SFPs and leaves the selecti on of SFIs to the local SFF; advertisement allows construction of valid SFPs and leaves the selecti on of SFIs to the local SFF;
the detailed advertisement may have scaling concerns, but allows a Con troller that constructs an a detailed advertisement may have scaling concerns but allows a contro ller that constructs an
SFP to make an explicit choice of SFI.</t> SFP to make an explicit choice of SFI.</t>
<t>Note that a node may advertise all its SFIs of one SFT in one shot
<t>Note that a node may advertise all its SFIs of one SFT in one shot usi using normal BGP UPDATE packing.
ng normal BGP Update packing.
That is, all of the SFIRs in an Update share a common Tunnel Encapsula tion and Route Target (RT) attribute. That is, all of the SFIRs in an Update share a common Tunnel Encapsula tion and Route Target (RT) attribute.
See also <xref target="sfpatt" />.</t> See also <xref target="sfpatt" format="default"/>.</t>
<t>The SFIR representing a given SFI will contain an NLRI with "RD" fiel
<t>The SFIR representing a given SFI will contain an NLRI with RD field s d set to an RD as specified above,
et to an RD as specified above, and with the "SFT" field set to identify that SFI's SFT. The values f
and with SFT field set to identify that SFI&apos;s Service Function Ty or the "SFT"
pe. The values for the SFT field are taken from a registry administered by IANA (see <xref target
field are taken from a registry administered by IANA (see <xref target ="iana" format="default"/>). A BGP UPDATE
="iana" />). A BGP Update containing one or more SFIRs <bcp14>MUST</bcp14> also include a tunnel
containing one or more SFIRs MUST also include a Tunnel Encapsulation encapsulation attribute
attribute <xref target="RFC9012" format="default"/>. If a data packet needs to
<xref target="I-D.ietf-idr-tunnel-encaps" />. If a data packet needs be sent to an SFI identified
to be sent to an SFI identified in one of the SFIRs, it will be encapsulated as specified by the tunne
in one of the SFIRs, it will be encapsulated as specified by the Tunne l encapsulation attribute and
l Encapsulation attribute, and
then transmitted through the underlay network.</t> then transmitted through the underlay network.</t>
<t>Note that the tunnel encapsulation attribute <bcp14>MUST</bcp14> cont
<t>Note that the Tunnel Encapsulation attribute MUST contain sufficient i ain sufficient information to allow the
nformation to allow the advertising SFF to identify the overlay or VPN network that a received
advertising SFF to identify the overlay or VPN network which a receive packet is transiting.
d packet is transiting.
This is because the [SPI, SI] in a received packet is specific to a pa rticular overlay or VPN This is because the [SPI, SI] in a received packet is specific to a pa rticular overlay or VPN
network.</t> network.</t>
<section anchor="poolid" numbered="true" toc="default">
<section anchor="poolid" title="SFIR Pool Identifier Extended Community"> <name>SFIR Pool Identifier Extended Community</name>
<t>This document defines a new transitive Extended Community <xref tar
<t>This document defines a new transitive extended community <xref tar get="RFC4360" format="default"/> of type 0x0b called
get="RFC4360" /> of type TBD6 called the "SFC Extended Community". When used with Sub-Type 1, this is c
the SFC extended community. When used with Sub-Type 1, this is cal alled the "SFIR Pool Identifier extended
led the SFIR Pool Identifier extended community". It <bcp14>MAY</bcp14> be included in SFIR
community. It MAY be included in SFIR advertisements, and is used advertisements, and it is used to indicate the identity of a pool of
to indicate the identity of a pool of SFIRs to which an SFIR belongs. Since an SFIR may be a member of
SFIRs to which an SFIR belongs. Since an SFIR may be a member of m more than one pool, multiple of these extended
ultiple pools, multiple of these extended
communities may be present on a single SFIR advertisement.</t> communities may be present on a single SFIR advertisement.</t>
<t>SFIR pools allow SFIRs to be grouped for any purpose. Possible use s include control plane scalability and <t>SFIR pools allow SFIRs to be grouped for any purpose. Possible use s include control plane scalability and
stability. A pool identifier may be included in an SFPR to indicat e a set of SFIs that are acceptable at stability. A pool identifier may be included in an SFPR to indicat e a set of SFIs that are acceptable at
a specific point on an SFP (see <xref target="sfttlv"/> and <xref t a specific point on an SFP (see Sections <xref format="counter"
arget="SFPR"/>).</t> target="sfttlv"/> and <xref target="SFPR" format="counter"/>).</t>
<t>The SFIR Pool Identifier Extended Community is encoded in 8 octets
<t>The SFIR Pool Identifier extended community is encoded in 8 octets as shown in <xref target="poolFig" format="default"/>.</t>
as shown in <xref target="poolFig"/>.</t> <figure anchor="poolFig">
<name>The SFIR Pool Identifier Extended Community</name>
<figure anchor="poolFig" title="The SFIR Pool Identifier Extended Comm <artwork name="" type="" align="left" alt=""><![CDATA[
unity">
<artwork>
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD6 (1 octet) | | Type = 0x0b (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| Sub-Type = 1 (1 octet) | | Sub-Type = 1 (1 octet) |
+--------------------------------------------+ +--------------------------------------------+
| SFIR Pool Identifier Value (6 octets) | | SFIR Pool Identifier value (6 octets) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t>The SFIR Pool Identifier value is encoded in a 6-octet field in net
<t>The SFIR Pool Identifier Value is encoded in a 6 octet field in net work byte order, and the value is unique
work byte order, and the value is unique
within the scope of an overlay network. This means that pool ident ifiers need to be centrally managed, which within the scope of an overlay network. This means that pool ident ifiers need to be centrally managed, which
is consistent with the assignment of SFIs to pools.</t> is consistent with the assignment of SFIs to pools.</t>
</section>
</section> <section anchor="swapnstack" numbered="true" toc="default">
<name>MPLS Mixed Swapping/Stacking Extended Community</name>
<section anchor="swapnstack" title="MPLS Mixed Swapping/Stacking Extended <t>As noted in <xref target="poolid" format="default"/>, this document
Community"> defines a new transitive Extended Community of type 0x0b
called the "SFC Extended Community". When used with Sub-Type 2, th
<t>As noted in <xref target="poolid" />, this document defines a new t is is called the "MPLS Mixed Swapping/Stacking
ransitive extended community of type TBD6 Labels Extended Community". The community is encoded as shown in <
called the SFC extended community. When used with Sub-Type 2, this xref target="swapFig" format="default"/>.
is called the MPLS Mixed Swapping/Stacking It contains a pair of MPLS labels: an SFC Context Label and an SF L
Labels extended community. The community is encoded as shown in <x abel, as described in
ref target="swapFig"/>. <xref target="RFC8595" format="default"/>. Each label is 20 bits e
It contains a pair of MPLS labels: an SFC Context Label and an SF L ncoded in a 3-octet (24-bit) field with
abel as described in 4 trailing bits that <bcp14>MUST</bcp14> be set to zero.</t>
<xref target="RFC8595"/>. Each label is 20 bits encoded in a 3-oct <figure anchor="swapFig">
et (24 bit) field with <name>The MPLS Mixed Swapping/Stacking Labels Extended Community</na
4 trailing bits that MUST be set to zero.</t> me>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure anchor="swapFig" title="The MPLS Mixed Swapping/Stacking Exten
ded Community">
<artwork>
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Type = TBD6 (1 octet) | | Type = 0x0b (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Sub-Type = 2 (1 octet) | | Sub-Type = 2 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| SFC Context Label (3 octets) | | SFC Context Label (3 octets) |
+--------------------------------------------| +--------------------------------------------|
| SF Label (3 octets) | | SF Label (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork>
</figure> </figure>
<t>Note that it is assumed that each SFF has one or more globally
<t>Note that it is assumed that each SFF has one or more globally uniq unique SFC Context Labels and that the context-label
ue SFC Context Labels and that the context label space and the SPI-address space are disjoint. In other words, a
space and the SPI address space are disjoint (i.e., a label value c label value cannot be used to indicate both an SFC context and an
annot be used both to indicate an SFC context and an SPI, SPI,
and it can be determined from knowledge of the label spaces whether and it can be determined from knowledge of the label spaces
a label indicates an SFC context or an SPI).</t> whether a label indicates an SFC context or an SPI.</t>
<t>If an SFF supports SFP Traversal with an MPLS Label Stack, it
<t>If an SFF supports SFP Traversal with an MPLS Label Stack it MUST i <bcp14>MUST</bcp14> include this Extended Community with the SFIRs
nclude this extended community with the SFIRs
that it advertises.</t> that it advertises.</t>
<t>See <xref target="swapOp" format="default"/> for a description of h
<t>See <xref target="swapOp"/> for a description of how this extended ow this Extended Community is used.</t>
community is used.</t> </section>
</section>
</section> <section anchor="sfpRoutes" numbered="true" toc="default">
<name>Service Function Path Route (SFPR)</name>
</section> <t><xref target="sfpRouteFig" format="default"/> shows the Route Type sp
ecific NLRI of the SFPR.</t>
<section anchor="sfpRoutes" title="Service Function Path Route (SFPR)"> <figure anchor="sfpRouteFig">
<name>SFPR Route Type Specific NLRI</name>
<t><xref target="sfpRouteFig" /> shows the Route Type specific NLRI of th <artwork name="" type="" align="left" alt=""><![CDATA[
e SFPR.</t>
<figure anchor="sfpRouteFig" title="SFPR Route Type Specific NLRI">
<artwork>
<![CDATA[
+-----------------------------------------------+ +-----------------------------------------------+
| Route Distinguisher (RD) (8 octets) | | Route Distinguisher (RD) (8 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
| Service Path Identifier (SPI) (3 octets) | | Service Path Identifier (SPI) (3 octets) |
+-----------------------------------------------+ +-----------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t><xref target="RFC4364" format="default"/> defines a Route Distinguish
er (RD) as consisting of a two-byte "Type" field
<t><xref target="RFC4364" /> defines a Route Distinguisher (RD) to consis and a six-byte "Value" field, and it defines RD types 0, 1, and 2. In
t of a two byte Type field this specification, the RD
and a six byte Value field and it defines RD types 0, 1, and 2. In th (used for the SFPR) <bcp14>MUST</bcp14> be of type 0, 1, or 2.</t>
is specification, the RD <t>All SFPs <bcp14>MUST</bcp14> be associated with an RD. The associati
(used for the SFPR) MUST be of type 0, 1, or 2.</t> on of an SFP with
an RD is determined by provisioning. If two SFPRs are originated from
<t>All SFPs MUST be associated with an RD. The association of an SFP wit different controllers, they
h <bcp14>MUST</bcp14> have different RDs. Additionally, SFPRs from diff
an RD is determined by provisioning. If two SFPRs are originated from erent VPNs (i.e., in different service
different Controllers they function overlay networks) <bcp14>MUST</bcp14> have different RDs, and
MUST have different RDs. Additionally, SFPRs from different VPNs (i.e those RDs <bcp14>MUST</bcp14> be different from any
., in different service
function overlay networks) MUST have different RDs, and those RDs MUST
be different from any
non-VPN SFPRs.</t> non-VPN SFPRs.</t>
<t>The Service path identifier is defined in <xref target="RFC8300" form
<t>The Service Path Identifier is defined in <xref target="RFC8300" /> an at="default"/> and is the value
d is the value to be placed in the "Service Path Identifier" field of the NSH of any
to be placed in the Service Path Identifier field of the NSH header of packet sent on this
any packet sent on this SFP. It is expected that one or more controllers will originate
Service Function Path. It is expected that one or more Controllers wi
ll originate
these routes in order to configure a service function overlay network. </t> these routes in order to configure a service function overlay network. </t>
<t>The SFP is described in a new BGP Path attribute, the SFP attribute.
<t>The SFP is described in a new BGP Path attribute, the SFP attribute. <xref target="sfpatt" format="default"/>
<xref target="sfpatt" />
shows the format of that attribute.</t> shows the format of that attribute.</t>
<section anchor="sfpatt" numbered="true" toc="default">
<section anchor="sfpatt" title="The SFP Attribute"> <name>The SFP Attribute</name>
<t><xref target="RFC4271" format="default"/> defines BGP Path attribut
<t><xref target="RFC4271" /> defines BGP Path attributes. This docume es. This document introduces a new
nt introduces a new Optional Transitive Path attribute called the "SFP attribute", with
Optional Transitive Path attribute called the SFP attribute with va value 37. The first SFP attribute <bcp14>MUST</bcp14> be processed, and subseq
lue TBD3 to be assigned uent instances <bcp14>MUST</bcp14> be ignored.</t>
by IANA. The first SFP attribute MUST be processed and subsequent
instances MUST be ignored.</t>
<t>The common fields of the SFP attribute are set as follows: <t>The common fields of the SFP attribute are set as follows:
<list style="symbols"> </t>
<t>Optional bit is set to 1 to indicate that this is an optional <ul spacing="normal">
attribute.</t> <li>The Optional bit is set to 1 to indicate that this is an optiona
<t>The Transitive bit is set to 1 to indicate that this is a tran l attribute.</li>
sitive attribute.</t> <li>The Transitive bit is set to 1 to indicate that this is a transi
<t>The Extended Length bit is set if the length of the SFP attrib tive attribute.</li>
ute is encoded in one <li>The Extended Length bit is set if the length of the SFP attribut
octet (set to 0) or two octets (set to 1) as described in <xre e is encoded in one
f target="RFC4271" />.</t> octet (set to 0) or two octets (set to 1), as described in <xr
<t>The Attribute Type Code is set to TBD3.</t> ef target="RFC4271" format="default"/>.</li>
</list></t> <li>The Attribute Type Code is set to 37.</li>
</ul>
<t>The content of the SFP attribute is a series of Type-Length-Value ( TLV) constructs. <t>The content of the SFP attribute is a series of Type-Length-Value ( TLV) constructs.
Some TLVs may include sub-TLVs. All TLVs and sub-TLVs have a commo Some TLVs may include Sub-TLVs. All TLVs and Sub-TLVs have a commo
n format that is: n format:
<list style="symbols"> </t>
<t>Type: A single octet indicating the type of the SFP attribute <dl>
TLV. Values are <dt>Type:</dt><dd> A single octet indicating the type of the SFP att
taken from the registry described in <xref target="ianasftlv" ribute TLV. Values are
/>.</t> taken from the registry described in <xref target="ianasftlv"
<t>Length: A two octet field indicating the length of the data fo format="default"/>.</dd>
llowing the Length <dt>Length:</dt><dd> A two-octet field indicating the length of the
field counted in octets.</t> data following the "Length"
<t>Value: The contents of the TLV.</t> field, counted in octets.</dd>
</list></t> <dt>Value:</dt><dd> The contents of the TLV.</dd>
</dl>
<t>The formats of the TLVs defined in this document are shown in the f ollowing sections. <t>The formats of the TLVs defined in this document are shown in the f ollowing sections.
The presence rules and meanings are as follows. The presence rules and meanings are as follows.
<list style="symbols"> </t>
<t>The SFP attribute contains a sequence of zero or more Associat <ul spacing="normal">
ion TLVs. That is, the <li>The SFP attribute contains a sequence of zero or more Associatio
Association TLV is OPTIONAL. Each Association TLV provides an n TLVs. That is, the
association between this Association TLV is <bcp14>OPTIONAL</bcp14>. Each Association
TLV provides an association between this
SFPR and another SFPR. Each associated SFPR is indicated usin g the RD with which it is SFPR and another SFPR. Each associated SFPR is indicated usin g the RD with which it is
advertised (we say the SFPR-RD to avoid ambiguity).</t> advertised (we say the SFPR-RD to avoid ambiguity).</li>
<li>The SFP attribute contains a sequence of one or more Hop TLVs.
<t>The SFP attribute contains a sequence of one or more Hop TLVs. Each Hop TLV contains
Each Hop TLV contains all of the information about a single hop in the SFP.</li>
all of the information about a single hop in the SFP.</t> <li>Each Hop TLV contains an SI value and a sequence of one or more
SFT TLVs. Each SFT
<t>Each Hop TLV contains an SI value and a sequence of one or mor
e SFT TLVs. Each SFT
TLV contains an SFI reference for each instance of an SF that is allowed at this hop TLV contains an SFI reference for each instance of an SF that is allowed at this hop
of the SFP for the specific SFT. Each SFI is indicated using the RD with which of the SFP for the specific SFT. Each SFI is indicated using the RD with which
it is advertised (we say the SFIR-RD to avoid ambiguity).</t> it is advertised (we say the SFIR-RD to avoid ambiguity).</li>
</list></t> </ul>
<t><xref target="RFC4271" section="6" sectionFormat="of"/> describes t
<t>Section 6 of <xref target="RFC4271"/> describes the handling of mal he handling of malformed BGP attributes,
formed BGP attributes, or those that are in error in some way. <xref target="RFC7606" for
or those that are in error in some way. <xref target="RFC7606" /> mat="default"/> revises BGP error handling
revises BGP error handling
specifically for the UPDATE message, provides guidelines for the au thors of documents specifically for the UPDATE message, provides guidelines for the au thors of documents
defining new attributes, and revises the error handling procedures for a number of existing defining new attributes, and revises the error-handling procedures for a number of existing
attributes. This document introduces the SFP attribute and so defi nes error handling as attributes. This document introduces the SFP attribute and so defi nes error handling as
follows: follows:
<list style="symbols"> </t>
<t>When parsing a message, an unknown Attribute Type code or a le <ul spacing="normal">
ngth that suggests that <li>When parsing a message, an unknown Attribute Type Code or a leng
the attribute is longer than the remaining message is treated th that suggests that
as a malformed message the attribute is longer than the remaining message is treated
and the "treat-as-withdraw" approach used as per <xref target= as a malformed message,
"RFC7606"/>.</t> and the "treat-as-withdraw" approach is used as per <xref targ
et="RFC7606" format="default"/>.</li>
<t>When parsing a message that contains an SFP attribute, the fol <li>
lowing cases constitute <t>When parsing a message that contains an SFP attribute, the foll
owing cases constitute
errors: errors:
<list style="numbers"> </t>
<t>Optional bit is set to 0 in SFP attribute.</t> <ol spacing="normal" type="1"><li>Optional bit is set to 0 in the
<t>Transitive bit is set to 0 in SFP attribute.</t> SFP attribute.</li>
<t>Unknown TLV type field found in SFP attribute.</t> <li>Transitive bit is set to 0 in the SFP attribute.</li>
<t>TLV length that suggests the TLV extends beyond the end o <li>Unknown "TLV Type" field found in the SFP attribute.</li>
f the SFP attribute.</t> <li>TLV length that suggests the TLV extends beyond the end of t
<t>Association TLV contains an unknown SFPR-RD.</t> he SFP attribute.</li>
<t>No Hop TLV found in the SFP attribute.</t> <li>Association TLV contains an unknown SFPR-RD.</li>
<t>No sub-TLV found in a Hop TLV.</t> <li>No Hop TLV found in the SFP attribute.</li>
<t>Unknown SFIR-RD found in an SFT TLV.</t> <li>No Sub-TLV found in a Hop TLV.</li>
</list></t> <li>Unknown SFIR-RD found in an SFT TLV.</li>
</ol>
<t>The errors listed above are treated as follows: </li>
<list style="hanging"> <li>
<t hangText="1., 2., 4., 6., 7.:">The attribute MUST be trea <t>The errors listed above are treated as follows:
ted as malformed and </t>
the "treat-as-withdraw" approach used as per <xref target= <dl newline="false" spacing="normal">
"RFC7606"/>.</t> <dt>1, 2, 4, 6, 7:</dt>
<t hangText="3.:">Unknown TLVs MUST be ignored, and message <dd>The attribute <bcp14>MUST</bcp14> be treated as malformed an
processing MUST d
continue.</t> the "treat-as-withdraw" approach used as per <xref target=
<t hangText="5., 8.:">The absence of an RD with which to cor "RFC7606" format="default"/>.</dd>
relate is nothing more than <dt>3:</dt>
a soft error. The receiver SHOULD store the information f <dd>Unknown TLVs <bcp14>MUST</bcp14> be ignored, and message pro
rom the SFP attribute until cessing <bcp14>MUST</bcp14>
a corresponding advertisement is received.</t> continue.</dd>
</list></t> <dt>5, 8:</dt>
</list></t> <dd>The absence of an RD with which to correlate is nothing more
than
<section anchor="assoctlv" title="The Association TLV"> a soft error. The receiver <bcp14>SHOULD</bcp14> store th
<t>The Association TLV is an optional TLV in the SFP attribute. It e information from the SFP attribute until
MAY be present a corresponding advertisement is received.</dd>
</dl>
</li>
</ul>
<section anchor="assoctlv" numbered="true" toc="default">
<name>The Association TLV</name>
<t>The Association TLV is an optional TLV in the SFP attribute. It
<bcp14>MAY</bcp14> be present
multiple times. Each occurrence provides an association with an other SFP as multiple times. Each occurrence provides an association with an other SFP as
advertised in another SFPR. The format of the Association TLV i s shown in advertised in another SFPR. The format of the Association TLV i s shown in
<xref target="assoctlvfig" /></t> <xref target="assoctlvfig" format="default"/>.</t>
<figure anchor="assoctlvfig">
<figure anchor="assoctlvfig" title="The Format of the Association T <name>The Format of the Association TLV</name>
LV"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Type = 1 (1 octet) | | Type = 1 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Association Type (1 octet) | | Association Type (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Associated SFPR-RD (8 octets) | | Associated SFPR-RD (8 octets) |
+--------------------------------------------| +--------------------------------------------|
| Associated SPI (3 octets) | | Associated SPI (3 octets) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The fields are as follows:
</t>
<t>The fields are as follows: <ul spacing="normal">
<list style="emtpy" > <li>"Type" is set to 1 to indicate an Association TLV.</li>
<t>Type is set to 1 to indicate an Association TLV.</t> <li>"Length" indicates the length in octets of the "Association Ty
<t>Length indicates the length in octets of the Association Ty pe" and "Associated
pe and Associated SFPR-RD" fields. The value of the "Length" field is 12.</l
SFPR-RD fields. The value of the Length field is 12.</t> i>
<t>The Association Type field indicate the type of association <li>The "Association Type" field indicates the type of association
. The values are . The values are
tracked in an IANA registry (see <xref target="ianaassoc" / tracked in an IANA registry (see <xref target="ianaassoc" f
>). Only one value ormat="default"/>). Only one value
is defined in this document: type 1 indicates association o is defined in this document: Type 1 indicates association o
f two unidirectional f two unidirectional
SFPs to form a bidirectional SFP. An SFP attribute SHOULD SFPs to form a bidirectional SFP. An SFP attribute <bcp14>
NOT contain more than SHOULD NOT</bcp14> contain more than
one Association TLV with Association Type 1: if more than o one Association TLV with Association Type 1; if more than o
ne is present, the ne is present, the
first one MUST be processed and subsequent instances MUST b first one <bcp14>MUST</bcp14> be processed, and subsequent
e ignored. Note that instances <bcp14>MUST</bcp14> be ignored. Note that
documents that define new Association Types must also defin documents that define new association types must also defin
e the presence rules e the presence rules
for Association TLVs of the new type.</t> for Association TLVs of the new type.</li>
<t>The Associated SFPR-RD contains the RD of the associated SF <li>The Associated SFPR-RD contains the RD of the associated SFP a
P as advertised in an s advertised in an
SFPR.</t> SFPR.</li>
<t>The Associated SPI contains the SPI of the associated SFP a <li>The Associated SPI contains the SPI of the associated SFP as a
s advertised in an dvertised in an
SFPR.</t> SFPR.</li>
</list></t> </ul>
<t>Association TLVs with unknown Association Type values <bcp14>SHOU
<t>Association TLVs with unknown Association Type values SHOULD be LD</bcp14> be ignored. Association TLVs
ignored. Association TLVs
that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are that contain an Associated SFPR-RD value equal to the RD of the SFPR in which they are
contained SHOULD be ignored. If the Associated SPI is not equal contained <bcp14>SHOULD</bcp14> be ignored. If the Associated S
to the SPI advertised in PI is not equal to the SPI advertised in
the SFPR indicated by the Associated SFPR-RD then the Associatio the SFPR indicated by the Associated SFPR-RD, then the Associati
n TLV SHOULD be ignored. on TLV <bcp14>SHOULD</bcp14> be ignored.
In all three of these cases an implementation MAY reject the SFP In all three of these cases, an implementation <bcp14>MAY</bcp14
attribute as malformed and > reject the SFP attribute as malformed and
use the "treat-as-withdraw" approach per <xref target="RFC7606"/ use the "treat-as-withdraw" approach per <xref target="RFC7606"
>, however implementers are format="default"/>; however, implementors are
cautioned that such an approach may make an implementation less flexible in the event of cautioned that such an approach may make an implementation less flexible in the event of
future extensions to this protocol.</t> future extensions to this protocol.</t>
<t>Note that when two SFPRs reference each other using the Associati
<t>Note that when two SFPRs reference each other using the Associat on TLV, one SFPR advertisement
ion TLV, one SFPR advertisement will be received before the other. Therefore, processing of an
will be received before the other. Therefore, processing of an association <bcp14>MUST NOT</bcp14> be
association MUST NOT be
rejected simply because the Associated SFPR-RD is unknown.</t> rejected simply because the Associated SFPR-RD is unknown.</t>
<t>Further discussion of correlation of SFPRs is provided in <xref t
<t>Further discussion of correlation of SFPRs is provided in <xref arget="correlation" format="default"/>.</t>
target="correlation" />.</t>
</section> </section>
<section anchor="hoptlv" numbered="true" toc="default">
<section anchor="hoptlv" title="The Hop TLV"> <name>The Hop TLV</name>
<t>There is one Hop TLV in the SFP attribute for each hop in the SF <t>There is one Hop TLV in the SFP attribute for each hop in the SFP
P. The format of . The format of
the Hop TLV is shown in <xref target="hoptlvfig" />. At least o the Hop TLV is shown in <xref target="hoptlvfig" format="default
ne Hop TLV MUST be "/>. At least one Hop TLV <bcp14>MUST</bcp14> be
present in an SFP attribute.</t> present in an SFP attribute.</t>
<figure anchor="hoptlvfig">
<figure anchor="hoptlvfig" title="The Format of the Hop TLV"> <name>The Format of the Hop TLV</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Type = 2 (1 octet) | | Type = 2 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Index (1 octet) | | Service Index (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Hop Details (variable) | | Hop Details (variable) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The fields are as follows:
</t>
<t>The fields are as follows: <ul spacing="normal">
<list style="emtpy" > <li>"Type" is set to 2 to indicate a Hop TLV.</li>
<t>Type is set to 2 to indicate a Hop TLV.</t> <li>"Length" indicates the length, in octets, of the "Service Inde
<t>Length indicates the length in octets of the Service Index x" and "Hop
and Hop Details" fields.</li>
Details fields.</t> <li>The Service Index is defined in <xref target="RFC8300" format=
<t>The Service Index is defined in <xref target="RFC8300" /> a "default"/> and is the value found in the
nd is the value found in the "Service Index" field of the NSH that an SFF will
Service Index field of the NSH header that an SFF will use use to look up to which next
to lookup to which next SFI a packet is to be sent.</li>
SFI a packet is to be sent.</t> <li>The "Hop Details" field consists of a sequence of one or more
<t>The Hop Details field consists of a sequence of one or more Sub-TLVs.</li>
sub-TLVs.</t> </ul>
</list></t> <t>Each hop of the SFP may demand that a specific type of SF is exec
uted, and that type is
<t>Each hop of the SFP may demand that a specific type of SF is exe indicated in Sub-TLVs of the Hop TLV. At least one Sub-TLV <bcp
cuted, and that type is 14>MUST</bcp14> be present. This document
indicated in sub-TLVs of the Hop TLV. At least one sub-TLV MUST defines the SFT Sub-TLV (see <xref target="sfttlv"
be present. This document format="default"/>) and the MPLS Swapping/Stacking Sub-TLV
defines the SFT Sub-TLV (see <xref target="sfttlv" /> and the MP (see <xref target="swapTLV" format="default"/>); other Sub-TLVs
LS Swapping/Stacking Sub-TLV may be defined in future. The SFT Sub-TLV
(see Section <xref target="swapTLV" />: other sub-TLVs may be de
fined in future. This
provides a list of which types of SF are acceptable at a specifi c hop, and for each type it provides a list of which types of SF are acceptable at a specifi c hop, and for each type it
allows a degree of control to be imposed on the choice of SFIs o allows a degree of control to be imposed on the choice of SFIs o
f that particular type.</t> f that particular type. The MPLS
Swapping/Stacking Sub-TLV indicates the type of SFC encoding to use
<t>If no Hop TLV is present in an SFP Attribute, it is a malformed in an MPLS label stack. </t>
attribute</t> <t>If no Hop TLV is present in an SFP attribute, it is a malformed a
ttribute.</t>
</section> </section>
<section anchor="sfttlv" numbered="true" toc="default">
<section anchor="sfttlv" title="The SFT Sub-TLV"> <name>The SFT Sub-TLV</name>
<t>The SFT Sub-TLV <bcp14>MAY</bcp14> be included in the list of Sub
<t>The SFT Sub-TLV MAY be included in the list of sub-TLVs of the H -TLVs of the Hop TLV. The format of the SFT Sub-TLV
op TLV. The format of the SFT Sub-TLV is shown in <xref target="sfttlvfig" format="default"/>. The Ho
is shown in <xref target="sfttlvfig" />. The Sub-TLV contains a p Sub-TLV contains a list of SFIR-RD values each taken from
list of SFIR-RD values each taken from
the advertisement of an SFI. Together they form a list of accep table SFIs of the indicated type.</t> the advertisement of an SFI. Together they form a list of accep table SFIs of the indicated type.</t>
<figure anchor="sfttlvfig">
<figure anchor="sfttlvfig" title="The Format of the SFT Sub-TLV"> <name>The Format of the SFT Sub-TLV</name>
<artwork> <artwork name="" type="" align="left" alt=""><![CDATA[
<![CDATA[
+--------------------------------------------+ +--------------------------------------------+
| Type = 3 (1 octet) | | Type = 3 (1 octet) |
+--------------------------------------------| +--------------------------------------------|
| Length (2 octets) | | Length (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| Service Function Type (2 octets) | | Service Function Type (2 octets) |
+--------------------------------------------| +--------------------------------------------|
| SFIR-RD List (variable) | | SFIR-RD List (variable) |
+--------------------------------------------+ +--------------------------------------------+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The fields are as follows:
</t>
<t>The fields are as follows: <ul>
<list style="emtpy" > <li>"Type" is set to 3 to indicate an SFT Sub-TLV.</li>
<t>Type is set to 3 to indicate an SFT Sub-TLV.</t> <li>"Length" indicates the length, in octets, of the "Service
<t>Length indicates the length in octets of the Service Functi Function Type" and "SFIR-RD List" fields.</li>
on Type and SFIR-RD List fields.</t> <li>The SFT value indicates the category (type) of SF that is to b
<t>The Service Function Type value indicates the category (typ e
e) of SF that is to be
executed at this hop. The types are as advertised for the SFs supported by the SFFs. executed at this hop. The types are as advertised for the SFs supported by the SFFs.
SFT values in the range 1-31 are Special Purpose SFT values SFT values in the range 1-31 are special-purpose SFT values
and have meanings defined by and have meanings defined by
the documents that describe them - the value 'Change Sequen the documents that describe them -- the value "Change Seque
ce' is defined in nce" is defined in
<xref target="changeseq" /> of this document.</t> <xref target="changeseq" format="default"/> of this documen
<t>The hop description is further qualified beyond the specifi t.</li>
cation of the SFTs by listing, for <li>The hop description is further qualified beyond the specificat
ion of the SFTs by listing, for
each SFT in each hop, the SFIs that may be used at the hop. The SFIs are identified using each SFT in each hop, the SFIs that may be used at the hop. The SFIs are identified using
the SFIR-RDs from the advertisements of the SFIs in the SFI Rs. Note that if the list contains the SFIR-RDs from the advertisements of the SFIs in the SFI Rs. Note that if the list contains
one or more SFIR Pool Identifiers, then for each the SFIR-R D list is effectively expanded to one or more SFIR Pool Identifiers, then for each, the SFIR- RD list is effectively expanded to
include the SFIR-RD of each SFIR advertised with that SFIR Pool Identifier. An SFIR-RD of value include the SFIR-RD of each SFIR advertised with that SFIR Pool Identifier. An SFIR-RD of value
zero has special meaning as described in <xref target="sele ction" />. Each entry in the list zero has special meaning, as described in <xref target="sel ection" format="default"/>. Each entry in the list
is eight octets long, and the number of entries in the list can be deduced from the value of the is eight octets long, and the number of entries in the list can be deduced from the value of the
Length field.</t> "Length" field.</li>
<t>Note that an SFIR-RD is of type 0, 1, or 2 (as described in <li>Note that an SFIR-RD is of type 0, 1, or 2 (as described in
<xref target="sfiRoutes" />. Thus the <xref target="sfiRoutes" format="default"/>). Thus, the
high order octet of an RD found in an SFIR-RD List always h high-order octet of an RD found in an SFIR-RD List always
as a value of 0x00. However, the high has a value of 0x00. However, the high-order octet of an
order octet of an SFIR Pool Identifier (an extended communi SFIR Pool Identifier (an Extended Community with "Type"
ty with Type field TBD6), will always field 0x0b) will always
have a non-zero value. This allows the node processing the have a nonzero value. This allows the node processing the
SFIR-RD List to distinguish between SFIR-RD list to distinguish between
the two types of list entry.</t> the two types of list entry.</li>
</list></t> </ul>
</section> </section>
<section anchor="swapTLV" numbered="true" toc="default">
<section anchor="swapTLV" title="MPLS Swapping/Stacking Sub-TLV"> <name>MPLS Swapping/Stacking Sub-TLV</name>
<t>The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero-lengt
<t>The MPLS Swapping/Stacking Sub-TLV (Type value 4) is a zero leng h Sub-TLV that is <bcp14>OPTIONAL</bcp14> in the Hop TLV
th sub-TLV that is OPTIONAL in the Hop TLV and is used when the data representation is MPLS (see <xref targ
and is used when the data representation is MPLS (see <xref targ et="representation" format="default"/>). When present, it indicates to
et="representation"/>). When present it indicates to the classifier imposing an MPLS label stack that the current hop
the Classifier imposing an MPLS label stack that the current hop is to use an {SFC Context Label, SF label} rather
is to use an {SFC Context Label, SF label} rather than an {SPI, SF} label pair. See <xref target="swapOp" format=
than an {SPI, SF} label pair. See <xref target="swapOp"/> for m "default"/> for more details.</t>
ore details.</t>
</section> </section>
<section anchor="sfpTraverse" numbered="true" toc="default">
<section anchor="sfpTraverse" title="SFP Traversal With MPLS Label Sta <name>SFP Traversal With MPLS Label Stack TLV</name>
ck TLV"> <t>The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a z
ero-length TLV that can be carried in the
<t>The SFP Traversal With MPLS Label Stack TLV (Type value 5) is a SFP attribute and indicates to the classifier and the SFFs on th
zero length TLV that can be carried in the e SFP that an MPLS label stack with label
SFP Attribute and indicates to the Classifier and the SFFs on th swapping/stacking is to be used for packets traversing the SFP.
e SFP that an MPLS label stack with label All of the SFFs specified at each of the SFP's
swapping/stacking is to be used for packets traversing the SFP. hops <bcp14>MUST</bcp14> have advertised an MPLS Mixed Swapping
All of the SFFs specified at each of the SFP&apos;s /Stacking Extended Community (see <xref target="swapnstack" format="default"/>)
hops MUST have advertised an MPLS Mixed Swapping/Stacking Exten
ded Community (see <xref target="swapnstack" />)
for the SFP to be considered usable.</t> for the SFP to be considered usable.</t>
</section> </section>
</section>
</section> <section anchor="sfparules" numbered="true" toc="default">
<name>General Rules for the SFP Attribute</name>
<section anchor="sfparules" title="General Rules For The SFP Attribute">
<t>It is possible for the same SFI, as described by an SFIR, to be use d in multiple SFPRs.</t> <t>It is possible for the same SFI, as described by an SFIR, to be use d in multiple SFPRs.</t>
<t>When two SFPRs have the same SPI but different SFPR-RDs, there can
<t>When two SFPRs have the same SPI but different SFPR-RDs there can b be three cases:
e three cases: </t>
<list style="symbols"> <ol type="1" spacing="normal">
<t>Two or more Controllers are originating SFPRs for the same SF <li>Two or more controllers are originating SFPRs for the same SFP.
P. In this case the In this case, the
content of the SFPRs is identical and the duplication is to e content of the SFPRs is identical, and the duplication is to
nsure receipt and ensure receipt and
to provide Controller redundancy.</t> provide controller redundancy.</li>
<t>There is a transition in content of the advertised SFP and th <li>There is a transition in content of the advertised SFP, and the
e advertisements may advertisements may
originate from one or more Controllers. In this case the con originate from one or more controllers. In this case, the co
tent of the SFPRs will be ntent of the SFPRs will be
different.</t> different.</li>
<t>The reuse of an SPI may result from a configuration error.</t <li>The reuse of an SPI may result from a configuration error.</li>
> </ol>
</list></t> <t>There is no way in any of these cases for the receiving SFF to know
which SFPR to process, and the
<t>In all cases, there is no way for the receiving SFF to know which
SFPR to process, and the
SFPRs could be received in any order. At any point in time, when multiple SFPRs have the SFPRs could be received in any order. At any point in time, when multiple SFPRs have the
same SPI but different SFPR-RDs, the SFF MUST use the SFPR with th e numerically lowest same SPI but different SFPR-RDs, the SFF <bcp14>MUST</bcp14> use t he SFPR with the numerically lowest
SFPR-RD when interpreting the RDs as 8-octet integers in network b yte order. The SFF SFPR-RD when interpreting the RDs as 8-octet integers in network b yte order. The SFF
SHOULD log this occurrence to assist with debugging.</t> <bcp14>SHOULD</bcp14> log this occurrence to assist with debugging
.</t>
<t>Furthermore, a Controller that wants to change the content of an S <t>Furthermore, a controller that wants to change the content of an SF
FP is RECOMMENDED to use a P is <bcp14>RECOMMENDED</bcp14> to use a
new SPI and so create a new SFP onto which the Classifiers can tra new SPI and so create a new SFP onto which the classifiers can tra
nsition packet flows before nsition packet flows before
the SFPR for the old SFP is withdrawn. This avoids any race condi tions with SFPR advertisements.</t> the SFPR for the old SFP is withdrawn. This avoids any race condi tions with SFPR advertisements.</t>
<t>Additionally, a controller <bcp14>SHOULD NOT</bcp14> reuse an SPI a
<t>Additionally, a Controller SHOULD NOT re-use an SPI after it has w fter it has withdrawn the SFPR that used it
ithdrawn the SFPR that used it until at least a configurable amount of time has passed. This tim
until at least a configurable amount of time has passed. This tim er <bcp14>SHOULD</bcp14> have a default of one
er SHOULD have a default of one
hour.</t> hour.</t>
</section>
</section> </section>
</section> </section>
<section anchor="mode" numbered="true" toc="default">
</section> <name>Mode of Operation</name>
<t>This document describes the use of BGP as a control plane to create and
<section anchor="mode" title="Mode of Operation"> manage a service
<t>This document describes the use of BGP as a control plane to create and m
anage a service
function overlay network.</t> function overlay network.</t>
<section anchor="rt" numbered="true" toc="default">
<section anchor="rt" title="Route Targets"> <name>Route Targets</name>
<t>The main feature introduced by this document is the ability to create
<t>The main feature introduced by this document is the ability to create multiple service
multiple service function overlay networks through the use of Route Targets (RTs) <xref
function overlay networks through the use of Route Targets (RTs) <xref target="RFC4364" format="default"/>.</t>
target="RFC4364" />.</t> <t>Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs.
The RT carried by a particular
<t>Every BGP UPDATE containing an SFIR or SFPR carries one or more RTs. SFIR or SFPR is determined by the provisioning of the route's originat
The RT carried by a particular or.</t>
SFIR or SFPR is determined by the provisioning of the route&apos;s ori <t>Every node in a service function overlay network is configured with o
ginator.</t> ne or more import RTs.
Thus, each SFF will import only the SFPRs with matching RTs, allowing
<t>Every node in a service function overlay network is configured with on the construction of
e or more import RTs. multiple service function overlay networks or the instantiation of SFC
Thus, each SFF will import only the SFPRs with matching RTs allowing t s
he construction of within a Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVPN
multiple service function overlay networks or the instantiation of Ser ) instance
vice Function Chains (see <xref target="private" format="default"/>). An SFF that has a pr
within an Layer 3 Virtual Private Network (L3VPN) or Ethernet VPN (EVP esence in multiple service function
N) instance overlay networks (i.e., one that imports more than one RT) will
(see <xref target="private" />). An SFF that has a presence in multip usually maintain separate forwarding
le service function
overlay networks (i.e., imports more than one RT) will usually maintai
n separate forwarding
state for each overlay network.</t> state for each overlay network.</t>
</section>
<section anchor="SFIR" numbered="true" toc="default">
<name>Service Function Instance Routes</name>
<t>The SFIR (see <xref target="sfiRoutes" format="default"/>) is used to
advertise the existence and location
of a specific SFI; it consists of:
</section> </t>
<ul spacing="normal">
<section anchor="SFIR" title="Service Function Instance Routes"> <li>The RT as just described.</li>
<li>A Service Function Type (SFT) that is the type of service function
<t>The SFIR (see <xref target="sfiRoutes" />) is used to advertise the ex that is
istence and location provided (such as "firewall").</li>
of a specific Service Function Instance and consists of: <li>A Route Distinguisher (RD) that is unique to a specific overlay.</
li>
<list style="symbols"> </ul>
</section>
<t>The RT as just described.</t> <section anchor="SFPR" numbered="true" toc="default">
<name>Service Function Path Routes</name>
<t>A Service Function Type (SFT) that is the type of service functi <t>The SFPR (see <xref target="sfpRoutes" format="default"/>)
on that is describes a specific path of an SFC.
provided (such as "firewall").</t>
<t>A Route Distinguisher (RD) that is unique to a specific overlay.
</t>
</list></t>
</section>
<section anchor="SFPR" title="Service Function Path Routes">
<t>The SFPR (see <xref target="sfpRoutes" />) describes a specific path o
f a Service Function Chain.
The SFPR contains the Service Path Identifier (SPI) used to identify t he SFP in the NSH The SFPR contains the Service Path Identifier (SPI) used to identify t he SFP in the NSH
in the data plane. It also contains a sequence of Service Indexes (SI s). Each SI in the data plane. It also contains a sequence of Service Indexes (SI s). Each SI
identifies a hop in the SFP, and each hop is a choice between one of m identifies a hop in the SFP, and each hop is a choice between one or m
ore SFIs.</t> ore SFIs.</t>
<t>As described in this document, each SFP route is identified in the
<t>As described in this document, each Service Function Path Route is ide
ntified in the
service function overlay network by an RD and an SPI. The SPI is uniq ue within a single service function overlay network by an RD and an SPI. The SPI is uniq ue within a single
VPN instance supported by the underlay network.</t> VPN instance supported by the underlay network.</t>
<t>The SFPR advertisement comprises:
<t>The SFPR advertisement comprises: </t>
<list style="symbols"> <ul spacing="normal">
<t>An RT as described in <xref target="rt" />.</t> <li>An RT as described in <xref target="rt" format="default"/>.</li>
<li>
<t>A tuple that identifies the SFPR <t>A tuple that identifies the SFPR.
<list style="symbols"> </t>
<t>An RD that identifies an advertisement of an SFPR.</t> <ul spacing="normal">
<t>The SPI that uniquely identifies this path within the VPN i <li>An RD that identifies an advertisement of an SFPR.</li>
nstance distinguished <li>The SPI that uniquely identifies this path within the VPN inst
by the RD. This SPI also appears in the NSH.</t> ance distinguished
</list></t> by the RD. This SPI also appears in the NSH.</li>
</ul>
<t>A series of Service Indexes. Each SI is used in the context of a </li>
particular SPI and <li>A series of SIs. Each SI is used in the context of a particular S
identifies one or more SFs (distinguished by their SFTs) and for PI and
each SF a set of identifies one or more SFs (distinguished by their SFTs). For
each SF, it identifies a set of
SFIs that instantiate the SF. The values of the SI indicate the order in which the SFIs that instantiate the SF. The values of the SI indicate the order in which the
SFs are to be executed in the SFP that is represented by the SPI. SFs are to be executed in the SFP that is represented by the SPI.
</t> </li>
<li>The SI is used in the NSH to identify the entries in the SFP. Not
<t>The SI is used in the NSH to identify the entries in the SFP. No e that the SI values
te that the SI values
have meaning only relative to a specific path. They have no sema ntic other than to indicate have meaning only relative to a specific path. They have no sema ntic other than to indicate
the order of Service Functions within the path and are assumed to the order of SFs within the path and are assumed to be monotonica
be monotonically lly
decreasing from the start to the end of the path <xref target="RF decreasing from the start to the end of the path <xref target="RF
C8300" />.</t> C8300" format="default"/>.</li>
<li>
<t>Each Service Index is associated with a set of one or more Servic <t>Each SI is associated with a set of one or more SFIs
e Function Instances that can be used to provide the indexed SF within the path. Each
that can be used to provide the indexed Service Function within t member of
he path. Each member of
the set comprises: the set comprises:
<list style="symbols"> </t>
<t>The RD used in an SFIR advertisement of the SFI.</t> <ul spacing="normal">
<t>The SFT that indicates the type of function as used in the <li>The RD used in an SFIR advertisement of the SFI.</li>
same SFIR advertisement <li>The SFT that indicates the type of function as used in the sam
of the SFI.</t> e SFIR advertisement
</list></t> of the SFI.</li>
</list></t> </ul>
</li>
<t>This may be summarized as follows where the notations "SFPR-RD" and "S </ul>
FIR-RD" are used <t>This may be summarized as follows, where the notations "SFPR-RD" and
"SFIR-RD" are used
to distinguish the two different RDs, and where "*" indicates a multip lier: to distinguish the two different RDs, and where "*" indicates a multip lier:
<list style="empty"> </t>
<t>RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }</t> <artwork>
</list></t> RT, {SFPR-RD, SPI}, m * {SI, {n * {SFT, p * SFIR-RD} } }
<t>Where: </artwork>
<list style="empty">
<t>RT: Route Target</t>
<t>SFPR-RD: The Route Descriptor of the Service Function Path Route
advertisement</t>
<t>SPI: Service Path Identifier used in the NSH</t>
<t>m: The number of hops in the Service Function Path</t>
<t>n: The number of choices of Service Function Type for a specific
hop</t>
<t>p: The number of choices of Service Function Instance for given
Service Function Type in a specific hop</t>
<t>SI: Service Index used in the NSH to indicate a specific hop</t>
<t>SFT: The Service Function Type used in the same advertisement of
the Service
Function Instance Route</t>
<t>SFIR-RD: The Route Descriptor used in an advertisement of the Se
rvice Function
Instance Route</t>
</list></t>
<t>That is, there can be multiple SFTs at a given hop as described in <xr <t>Where:
ef target="selection"/>.</t> </t>
<t>Note that the values of SI are from the set {255, ..., 1} and are mono <dl>
tonically decreasing <dt>RT:</dt><dd> Route Target</dd>
within the SFP. SIs MUST appear in order within the SFPR (i.e., monot <dt>SFPR-RD:</dt><dd>The Route Descriptor of the SFPR advertisement</d
onically decreasing) d>
and MUST NOT appear more than once. Gaps MAY appear in the sequence a <dt>SPI:</dt><dd>Service Path Identifier used in the NSH</dd>
s described in <dt>m:</dt><dd>The number of hops in the SFP</dd>
<xref target="lacunae" />. Malformed SFPRs MUST be discarded and MUST <dt>n:</dt><dd>The number of choices of SFT for a specific hop</dd>
cause any <dt>p:</dt><dd>The number of choices of SFI
for a given SFT in a specific hop</dd>
<dt>SI:</dt><dd>Service Index used in the NSH to indicate a specific h
op</dd>
<dt>SFT:</dt><dd>The Service Function Type used in the same advertisem
ent of the SFIR
</dd>
<dt>SFIR-RD:</dt><dd>The Route Descriptor used in an advertisement of
the SFIR</dd>
</dl>
<t>That is, there can be multiple SFTs at a given hop, as described in <
xref target="selection" format="default"/>.</t>
<t>Note that the values of SI are from the set {255, ..., 1} and are mon
otonically decreasing
within the SFP. SIs <bcp14>MUST</bcp14> appear in order within the SF
PR (i.e., monotonically decreasing)
and <bcp14>MUST NOT</bcp14> appear more than once. Gaps <bcp14>MAY</b
cp14> appear in the sequence, as described in
<xref target="lacunae" format="default"/>. Malformed SFPRs <bcp14>MUS
T</bcp14> be discarded and <bcp14>MUST</bcp14> cause any
previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.< /t> previous instance of the SFPR (same SFPR-RD and SPI) to be discarded.< /t>
<t>Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR
<t>Note that if the SFIR-RD list in an SFT TLV contains one or more SFIR Pool Identifiers, then
Pool identifiers, then in the above expression, "p" is the sum of the number of individual SF
in the above expression, &apos;p&apos; is the sum of the number of ind IR-RD values
ividual SFIR-RD values
and the sum for each SFIR Pool Identifier of the number of SFIRs adver tised with that SFIR Pool and the sum for each SFIR Pool Identifier of the number of SFIRs adver tised with that SFIR Pool
Identifier. I.e., the list of SFIR-RD values is effectively expanded to include the SFIR-RD Identifier. In other words, the list of SFIR-RD values is effectively expanded to include the SFIR-RD
of each SFIR advertised with each SFIR Pool Identifier in the SFIR-RD list.</t> of each SFIR advertised with each SFIR Pool Identifier in the SFIR-RD list.</t>
<t>The choice of SFI is explained further in <xref target="selection" fo
<t>The choice of SFI is explained further in <xref target="selection" />. rmat="default"/>. Note that an SFIR-RD
Note that an SFIR-RD value of zero has special meaning, as described in that section.</t>
value of zero has special meaning as described in that Section.</t> </section>
<section anchor="classy" numbered="true" toc="default">
</section> <name>Classifier Operation</name>
<t>As shown in <xref target="SFCarch" format="default"/>, the classifier
<section anchor="classy" title="Classifier Operation"> is a component that is used to assign
<t>As shown in <xref target="SFCarch" />, the Classifier is a component
that is used to assign
packets to an SFP.</t> packets to an SFP.</t>
<t>The classifier is responsible for determining to which packet flow a
<t>The Classifier is responsible for determining to which packet flow a packet belongs. The
packet belongs. The mechanism it uses to achieve that classification is out of the scope
mechanism it uses to achieve that classification is out of scope of t of this document but might
his document, but might include inspection of the packet header. The classifier has been ins
include inspection of the packet header. The Classifier has been ins tructed (by the controller
tructed (by the Controller or through some other configuration mechanism -- see <xref target="fs
or through some other configuration mechanism - see <xref target="fsp pecclassy" format="default"/>) which flows
ecclassy" />) which flows
are to be assigned to which SFPs, and so it can impose an NSH on each packet and initialize the are to be assigned to which SFPs, and so it can impose an NSH on each packet and initialize the
NSH with the SPI of the selected SFP and the SI of its first hop.</t> NSH with the SPI of the selected SFP and the SI of its first hop.</t>
<t>Note that instructions delivered to the classifier may include inform
<t>Note that instructions delivered to the Classifier may include inform ation about the metadata
ation about the metadata to encode (and the format for that encoding) on packets that are clas
to encode (and the format for that encoding) on packets that are clas sified by the classifier
sified by the Classifier to a particular SFP. As mentioned in <xref target="ctrlover" format=
to a particular SFP. As mentioned in <xref target="ctrlover" />, thi "default"/>, this corresponds to the
s corresponds to the fifth element of control plane functionality described in <xref targe
fifth element of control plane functionality described in <xref targe t="RFC7665" format="default"/>. Such
t="RFC7665" />. Such instructions fall outside the scope of this specification (but
instructions fall outside the scope of this specification (although, see <xref target="fspecclassy" format="default"/>),
see <xref target="fspecclassy" />), as do instructions to other service function chaining elements on how
as do instructions to other SFC elements on how to interpret metadata to interpret metadata (as described in the
(as described in the sixth element of control plane functionality described in <xref targe
sixth element of control plane functionality described in <xref targe t="RFC7665" format="default"/>).</t>
t="RFC7665" />.</t> </section>
<section anchor="SFF" numbered="true" toc="default">
</section> <name>Service Function Forwarder Operation</name>
<t>Each packet sent to an SFF is transmitted encapsulated in an NSH. Th
<section anchor="SFF" title="Service Function Forwarder Operation"> e NSH includes an SPI
and SI: the SPI indicates the SFPR advertisement that announced the SF
<t>Each packet sent to an SFF is transmitted encapsulated in an NSH. The P;
NSH includes an SPI
and SI: the SPI indicates the SFPR advertisement that announced the Se
rvice Function Path;
the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a the tuple SPI/SI indicates a specific hop in a specific path and maps to the RD/SFT of a
particular SFIR advertisement.</t> particular SFIR advertisement.</t>
<t>When an SFF gets an SFPR advertisement, it will first determine wheth
<t>When an SFF gets an SFPR advertisement it will first determine whether er to import the route
to import the route by examining the RT. If the SFPR is imported, the SFF then determines
by examining the RT. If the SFPR is imported the SFF then determines whether it is on the
whether it is on the
SFP by looking for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For each SFP by looking for its own SFIR-RDs or any SFIR-RD with value zero in the SFPR. For each
occurrence in the SFP, the SFF creates forwarding state for incoming p ackets and forwarding occurrence in the SFP, the SFF creates forwarding state for incoming p ackets and forwarding
state for outgoing packets that have been processed by the specified S FI.</t> state for outgoing packets that have been processed by the specified S FI.</t>
<t>The SFF creates local forwarding state for packets that it receives f
<t>The SFF creates local forwarding state for packets that it receives fr rom other SFFs. This
om other SFFs. This
state makes the association between the SPI/SI in the NSH of the recei ved packet and one or state makes the association between the SPI/SI in the NSH of the recei ved packet and one or
more specific local SFIs as identified by the SFIR-RD/SFT. If there a more specific local SFIs, as identified by the SFIR-RD/SFT. If there
re multiple local SFIs are multiple local SFIs
that match this is because a single advertisement was made for a set o that match, this is because a single advertisement was made for a set
f equivalent SFIs and of equivalent SFIs, and
the SFF may use local policy (such as load balancing) to determine to which SFI to forward a the SFF may use local policy (such as load balancing) to determine to which SFI to forward a
received packet.</t> received packet.</t>
<t>The SFF also creates next-hop forwarding state for packets received b
<t>The SFF also creates next hop forwarding state for packets received ba ack from the local SFI
ck from the local SFI that need to be forwarded to the next hop in the SFP. There may be a
that need to be forwarded to the next hop in the SFP. There may be a choice of next hops,
choice of next hops as described in <xref target="SFPR" format="default"/>. The SFF could
as described in <xref target="SFPR" />. The SFF could install forward install forwarding state for all
ing state for all potential next hops or it could choose to only install forwarding stat
potential next hops, or it could choose to only install forwarding sta e for a subset of the
te to a subset of the potential next hops. If a choice is made, then it will be as describe
potential next hops. If a choice is made then it will be as described d in
in <xref target="selection" format="default"/>.</t>
<xref target="selection" />.</t> <t>The installed forwarding state may change over time, reacting to chan
ges in the underlay network
<t>The installed forwarding state may change over time reacting to change
s in the underlay network
and the availability of particular SFIs. Note that the forwarding sta te describes how one SFF and the availability of particular SFIs. Note that the forwarding sta te describes how one SFF
send packets to another SFF, but not how those packets are routed thro ugh the underlay network. sends packets to another SFF, but not how those packets are routed thr ough the underlay network.
SFFs may be connected by tunnels across the underlay, or packets may b e sent addressed to the SFFs may be connected by tunnels across the underlay, or packets may b e sent addressed to the
next SFF and routed through the underlay. In any case, transmission a cross the underlay requires next SFF and routed through the underlay. In any case, transmission a cross the underlay requires
encapsulation of packets with a header for transport in the underlay n etwork.</t> encapsulation of packets with a header for transport in the underlay n etwork.</t>
<t>Note that SFFs only create and store forwarding state for the SFPs on
<t>Note that SFFs only create and store forwarding state for the SFPs on which they are included.
which they are included.
They do not retain state for all SFPs advertised.</t> They do not retain state for all SFPs advertised.</t>
<t>An SFF may also install forwarding state to support looping, jumping,
<t>An SFF may also install forwarding state to support looping, jumping, and branching.
and branching.
The protocol mechanism for explicit control of looping, jumping, and The protocol mechanism for explicit control of looping, jumping, and
branching uses a specific reserved SFT value at a given hop of an SFPR and is described in branching uses a specific reserved SFT value at a given hop of an SFPR and is described in
<xref target="changeseq" />.</t> <xref target="changeseq" format="default"/>.</t>
<section anchor="lacunae" numbered="true" toc="default">
<section anchor="lacunae" title="Processing With &apos;Gaps&apos; in the <name>Processing with "Gaps" in the SI Sequence</name>
SI Sequence"> <t>The behavior of an SF, as described in <xref target="RFC8300" forma
t="default"/>, is to decrement
<t>The behavior of an SF as described in <xref target="RFC8300" /> is the value of the "SI" field in the NSH by one before returning a pa
to decrement cket to the local SFF for
the value of the SI field in the NSH by one before returning a pack
et to the local SFF for
further processing. This means that there is a good reason to assu me that the SFP is further processing. This means that there is a good reason to assu me that the SFP is
composed of a series of SFs each indicated by an SI value one less composed of a series of SFs, each indicated by an SI value one less
than the previous.</t> than the previous.</t>
<t>However, there is an advantage to having nonsuccessive SIs in an S
<t>However, there is an advantage to having non-successive SIs in an PI. Consider the case
SPI. Consider the case where an SPI needs to be modified by the insertion or removal of an
where an SPI needs to be modified by the insertion or removal of an SF. In the latter case,
SF. In the latter case
this would lead to a "gap" in the sequence of SIs, and in the forme r case, this could only this would lead to a "gap" in the sequence of SIs, and in the forme r case, this could only
be achieved if a gap already existed into which the new SF with its new SI value could be be achieved if a gap already existed into which the new SF with its new SI value could be
inserted. Otherwise, all "downstream" SFs would need to be renumbe red.</t> inserted. Otherwise, all "downstream" SFs would need to be renumbe red.</t>
<t>Now, of course, such renumbering could be performed, but it would l
<t>Now, of course, such renumbering could be performed, but would lead ead to a significant
to a significant
disruption to the SFC as all the SFFs along the SFP were "reprogram med". Thus, to achieve disruption to the SFC as all the SFFs along the SFP were "reprogram med". Thus, to achieve
dynamic modification of an SFP (and even, in-service modification) it is desirable to be dynamic modification of an SFP (and even in-service modification), it is desirable to be
able to make these modifications without changing the SIs of the el ements that were able to make these modifications without changing the SIs of the el ements that were
present before the modification. This will produce much more consi stent/predictable present before the modification. This will produce much more consi stent/predictable
behavior during the convergence period where otherwise the change w ould need to be behavior during the convergence period, where otherwise the change would need to be
fully propagated.</t> fully propagated.</t>
<t>Another approach says that any change to an SFP simply creates a ne w SFP that can be <t>Another approach says that any change to an SFP simply creates a ne w SFP that can be
assigned a new SPI. All that would be needed would be to give a ne w instruction to the assigned a new SPI. All that would be needed would be to give a ne w instruction to the
Classifier and traffic would be switched to the new SFP that contai classifier, and traffic would be switched to the new SFP that conta
ns the new set of SFs. ins the new set of SFs.
This approach is practical, but neglects to consider that the SFP m This approach is practical but neglects to consider that the SFP ma
ay be referenced by y be referenced by
other SFPs (through "branch" instructions) and used by many Classif other SFPs (through "branch" instructions) and used by many classif
iers. In those cases iers. In those cases,
the corresponding configuration resulting from a change in SPI may have wide ripples and the corresponding configuration resulting from a change in SPI may have wide ripples and
give scope for errors that are hard to trace.</t> create scope for errors that are hard to trace.</t>
<t>Therefore, while this document requires that the SI values in an SF
<t>Therefore, while this document requires that the SI values in an SF P are monotonically decreasing,
P are monotonic decreasing,
it makes no assumption that the SI values are sequential. Configur ation tools may apply it makes no assumption that the SI values are sequential. Configur ation tools may apply
that rule, but they are not required to. To support this, an SFF S HOULD process as follows that rule, but they are not required to. To support this, an SFF < bcp14>SHOULD</bcp14> process as follows
when it receives a packet: when it receives a packet:
<list style="symbols"> </t>
<t>If the SI indicates a known entry in the SFP, the SFF MUST pr <ul spacing="normal">
ocess the packet as <li>If the SI indicates a known entry in the SFP, the SFF <bcp14>MUS
normal, looking up the SI and determining to which local SFI T</bcp14> process the packet as
to deliver the packet.</t> normal, looking up the SI and determining to which local SFI
<t>If the SI does not match an entry in the SFP, the SFF MUST re to deliver the packet.</li>
duce the SI value to the <li>If the SI does not match an entry in the SFP, the SFF <bcp14>MUS
next (smaller) value present in the SFP and process the packe T</bcp14> reduce the SI value to the
t using that SI.</t> next (smaller) value present in the SFP and process the packe
<t>If there is no smaller SI (i.e., if the end of the SFP has be t using that SI.</li>
en reached) the SFF MUST <li>If there is no smaller SI (i.e., if the end of the SFP has been
treat the SI value as invalid as described in <xref target="R reached), the SFF <bcp14>MUST</bcp14>
FC8300" />.</t> treat the SI value as not valid, as described in <xref target
</list> ="RFC8300" format="default"/>.</li>
</ul>
<t>
This makes the behavior described in this document a superset of th e function in This makes the behavior described in this document a superset of th e function in
<xref target="RFC8300" />. That is, an implementation that strictl <xref target="RFC8300" format="default"/>. That is, an implementat
y follows RFC 8300 in ion that strictly follows RFC 8300 in
performing SI decrements in units of one, is perfectly in line with performing SI decrements in units of one is perfectly in line with
the mechanisms the mechanisms
defined in this document.</t> defined in this document.</t>
<t>SFF implementations <bcp14>MAY</bcp14> choose to only support conti
<t>SFF implementations MAY choose to only support contiguous SI values guous SI values in an SFP. Such an
in an SFP. Such an
implementation will not support receiving an SI value that is not p resent in the SFP and implementation will not support receiving an SI value that is not p resent in the SFP and
will discard the packets as described in <xref target="RFC8300" />. will discard the packets as described in <xref target="RFC8300" for
</t> mat="default"/>.</t>
</section>
</section> </section>
</section> </section>
<section anchor="selection" numbered="true" toc="default">
</section> <name>Selection within Service Function Paths</name>
<t>As described in <xref target="overview" format="default"/>, the SPI/SI
<section anchor="selection" title="Selection within Service Function Paths"> in the NSH passed back from an SFI to
the SFF may leave the SFF with a choice of next-hop SFTs and a choice of
<t>As described in <xref target="overview" /> the SPI/SI in the NSH passed b SFIs for each SFT.
ack from an SFI to
the SFF may leave the SFF with a choice of next hop SFTs, and a choice of
SFIs for each SFT.
That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in That is, the SPI indicates an SFPR, and the SI indicates an entry in that SFPR. Each entry in
an SFPR is a set of one or more SFT/SFIR-RD pairs. The SFF MUST choose o an SFPR is a set of one or more SFT/SFIR-RD pairs. The SFF <bcp14>MUST</
ne of these, identify bcp14> choose one of these, identify
the SFF that supports the chosen SFI, and send the packet to that next ho the SFF that supports the chosen SFI, and send the packet to that next-ho
p SFF.</t> p SFF.</t>
<t>The choice be may offered for load balancing across multiple SFIs, or f
<t>The choice be may offered for load balancing across multiple SFIs, or for or discrimination between
discrimination between
different actions necessary at a specific hop in the SFP. Different SFT values may exist at different actions necessary at a specific hop in the SFP. Different SFT values may exist at
a given hop in an SFP to support several cases: a given hop in an SFP to support several cases:
<list style="symbols"> </t>
<t>There may be multiple instances of similar service functions that ar <ul spacing="normal">
e distinguished by <li>There may be multiple instances of similar service functions that ar
e distinguished by
different SFT values. For example, firewalls made by vendor A and v endor B may need to different SFT values. For example, firewalls made by vendor A and v endor B may need to
be identified by different SFT values because, while they have simil ar functionality, their be identified by different SFT values because, while they have simil ar functionality, their
behavior is not identical. Then, some SFPs may limit the choice of SF at a given hop by behavior is not identical. Then, some SFPs may limit the choice of SF at a given hop by
specifying the SFT for vendor A, but other SFPs might not need to co specifying the SFT for vendor A, but other SFPs might not need to co
ntrol which vendor&apos;s ntrol which vendor's
SF is used and so can indicate that either SFT can be used.</t> SF is used and so can indicate that either SFT can be used.</li>
<t>There may be an obvious branch needed in an SFP such as the processi <li>There may be an obvious branch needed in an SFP, such as the process
ng after a firewall ing after a firewall
where admitted packets continue along the SFP, but suspect packets a re diverted to a where admitted packets continue along the SFP, but suspect packets a re diverted to a
"penalty box". In this case, the next hop in the SFP will be indica ted with two "penalty box". In this case, the next hop in the SFP will be indica ted with two
different SFT values.</t> different SFT values.</li>
</list></t> </ul>
<t>In the typical case, the SFF chooses a next-hop SFF by looking at the s
<t>In the typical case, the SFF chooses a next hop SFF by looking at the set et of all SFFs that
of all SFFs that
support the SFs identified by the SI (that set having been advertised in individual SFIR support the SFs identified by the SI (that set having been advertised in individual SFIR
advertisements), finding the one or more that are "nearest" in the underl ay network, and advertisements), finding the one or more that are "nearest" in the underl ay network, and
choosing between next hop SFFs using its own load-balancing algorithm.</t choosing between next-hop SFFs using its own load-balancing algorithm.</t
> >
<t>An SFI may influence this choice process by passing additional informat
<t>An SFI may influence this choice process by passing additional informatio ion back, along
n back along with the packet and NSH. This information may influence local policy
with the packet and NSH. This information may influence local policy at at the SFF to either cause it to favor a next-hop SFF (perhaps selecting
the SFF to cause one
it to favor a next hop SFF (perhaps selecting one that is not nearest in that is not nearest in the underlay) or influence the load-balancing algo
the underlay), or rithm.</t>
to influence the load-balancing algorithm.</t> <t>This selection applies to the normal case but also applies in the case
of looping,
<t>This selection applies to the normal case, but also applies in the case o jumping, and branching (see <xref target="looping" format="default"/>).</
f looping, t>
jumping, and branching (see <xref target="looping" />).</t>
<t>Suppose an SFF in a particular service overlay network (identified by a p articular import <t>Suppose an SFF in a particular service function overlay network (identi fied by a particular import
RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y. RT, RT-z) needs to forward an NSH-encapsulated packet whose SPI is SPI-x and whose SI is SI-y.
It does the following: It does the following:
<list style="numbers"> </t>
<ol spacing="normal" type="1"><li>It looks for an installed SFPR that carr
<t>It looks for an installed SFPR that carries RT-z and that has SPI-x ies RT-z and has SPI-x in its NLRI.
in its NLRI. If there is none, then such packets cannot be forwarded.</li>
If there is none, then such packets cannot be forwarded.</t> <li>From the SFP attribute of that SFPR, it finds the Hop TLV with SI va
lue set to SI-y.
<t>From the SFP attribute of that SFPR, it finds the Hop TLV with SI v If there is no such Hop TLV, then such packets cannot be forwarded.
alue set to SI-y. </li>
If there is no such Hop TLV, then such packets cannot be forwarded. <li>
</t>
<t>It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs <t>It then finds the "relevant" set of SFIRs by going through the list of SFT TLVs
contained in the Hop TLV as follows: contained in the Hop TLV as follows:
<list style="letters"> </t>
<t>An SFIR is relevant if it carries RT-z, the SFT in its NLRI m <ol spacing="normal" type="A"><li>An SFIR is relevant if it carries RT
atches -z, the SFT in its NLRI matches
the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches the SFT value in one of the SFT TLVs, and the RD value in its NLRI matches
an entry in the list of SFIR-RDs in that SFT TLV.</t> an entry in the list of SFIR-RDs in that SFT TLV.</li>
<t>If an entry in the SFIR-RD list of an SFT TLV contains the va <li>If an entry in the SFIR-RD list of an SFT TLV contains the value
lue zero, then zero, then
an SFIR is relevant if it carries RT-z and the SFT in its NLR I matches an SFIR is relevant if it carries RT-z and the SFT in its NLR I matches
the SFT value in that SFT TLV. I.e., any SFIR in the service the SFT value in that SFT TLV. That is, any SFIR in the serv
function ice function
overlay network defined by RT-z and with the correct SFT is r overlay network defined by RT-z and with the correct SFT is r
elevant.</t> elevant.</li>
<t>If a pool identifier is in use then an SFIR is relevant if it <li>If a pool identifier is in use, then an SFIR is relevant if it i
is a member of s a member of
the pool.</t> the pool.</li>
</list></t> </ol>
</li>
</list></t> </ol>
<t>Each of the relevant SFIRs identifies a single SFI and contains a tunne
<t>Each of the relevant SFIRs identifies a single SFI, and contains a Tunnel l encapsulation
Encapsulation
attribute that specifies how to send a packet to that SFI. For a particu lar packet, the attribute that specifies how to send a packet to that SFI. For a particu lar packet, the
SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according SFF chooses a particular SFI from the set of relevant SFIRs. This choice is made according
to local policy.</t> to local policy.</t>
<t>A typical policy might be to figure out the set of SFIs that are closes
<t>A typical policy might be to figure out the set of SFIs that are closest, t and load balance
and to load balance
among them. But this is not the only possible policy.</t> among them. But this is not the only possible policy.</t>
<t>Thus, at any point in time when an SFF selects its next hop, it chooses
<t>Thus, at any point in time when an SFF selects its next hop, it chooses f from the intersection
rom the intersection of the set of next-hop RDs contained in the SFPR and the RDs contained in
of the set of next hop RDs contained in the SFPR and the RDs contained in the SFF's local set of
the SFF&apos;s local set of
SFIRs (i.e., according to the determination of "relevance", above). If t he intersection is SFIRs (i.e., according to the determination of "relevance", above). If t he intersection is
null, the SFPR is unusable. Similarly, when this condition applies on th null, the SFPR is unusable. Similarly, when this condition applies on th
e Controller that originated e controller that originated
the SFPR, it SHOULD either withdraw the SFPR or re-advertise it with a ne the SFPR, it <bcp14>SHOULD</bcp14> either withdraw the SFPR or re-adverti
w set of RDs for the affected se it with a new set of RDs for the affected
hop.</t> hop.</t>
</section>
</section> <section anchor="looping" numbered="true" toc="default">
<name>Looping, Jumping, and Branching</name>
<section anchor="looping" title="Looping, Jumping, and Branching"> <t>As described in <xref target="overview" format="default"/>, an SFI or a
n SFF may cause a packet to
<t>As described in <xref target="overview" /> an SFI or an SFF may cause a p
acket to
"loop back" to a previous SF on a path in order that a sequence of functi ons may be "loop back" to a previous SF on a path in order that a sequence of functi ons may be
re-executed. This is simply achieved by replacing the SI in the NSH with re-executed. This is simply achieved by replacing the SI in the NSH with
a higher value a higher value,
instead of decreasing it as would normally be the case to determine the n instead of decreasing it as would normally be the case, to determine the
ext hop in the next hop in the
path.</t> path.</t>
<t><xref target="overview" format="default"/> also describes how an SFI or
<t><xref target="overview" /> also describes how an SFI or an SFF may cause SFF may cause a packet to
a packets to
"jump forward" to an SF on a path that is not the immediate next SF in th e SFP. This "jump forward" to an SF on a path that is not the immediate next SF in th e SFP. This
is simply achieved by replacing the SI in the NSH with a lower value than would be is simply achieved by replacing the SI in the NSH with a lower value than would be
achieved by decreasing it by the normal amount.</t> achieved by decreasing it by the normal amount.</t>
<t>A more complex option to move packets from one SFP to another is descri
<t>A more complex option to move packets from one SFP to another is describe bed in
d in <xref target="RFC8300" format="default"/> and <xref target="overview"
<xref target="RFC8300" /> and <xref target="overview" /> where it is term format="default"/>, where it is termed
ed
"branching". This mechanism allows an SFI or SFF to make a choice of dow nstream "branching". This mechanism allows an SFI or SFF to make a choice of dow nstream
treatments for packets based on local policy and output of the local SF. Branching is treatments for packets based on local policy and the output of the local SF. Branching is
achieved by changing the SPI in the NSH to indicate the new path and sett ing the SI to achieved by changing the SPI in the NSH to indicate the new path and sett ing the SI to
indicate the point in the path at which the packets enter.</t> indicate the point in the path at which the packets enter.</t>
<t>Note that the NSH does not include a marker to indicate whether a speci
<t>Note that the NSH does not include a marker to indicate whether a specifi fic packet has
c packet has been around a loop before. Therefore, the use of NSH metadata <xref targ
been around a loop before. Therefore, the use of NSH metadata (<xref tar et="RFC8300" format="default"/>
get="RFC8300" />)
may be required in order to prevent infinite loops.</t> may be required in order to prevent infinite loops.</t>
<section anchor="changeseq" numbered="true" toc="default">
<section anchor="changeseq" title="Protocol Control of Looping, Jumping, and <name>Protocol Control of Looping, Jumping, and Branching</name>
Branching"> <t>If the SFT value in an SFT TLV in an SFPR has the special-purpose SFT
value "Change
<t>If the SFT value in an SFT TLV in an SFPR has the Special Purpose SFT Sequence" (see <xref target="iana" format="default"/>), then this is a
value "Change n indication that the SFF may
Sequence" (see <xref target="iana" />) then this is an indication that
the SFF may
make a loop, jump, or branch according to local policy and information returned by make a loop, jump, or branch according to local policy and information returned by
the local SFI.</t> the local SFI.</t>
<t>In this case, the SPI and SI of the next hop are encoded in the eight
<t>In this case, the SPI and SI of the next hop are encoded in the eight bytes of an entry
bytes of an entry
in the SFIR-RD list as follows: in the SFIR-RD list as follows:
<list style="empty"> </t>
<t>3 bytes SPI</t> <ul empty="true" spacing="normal">
<t>1 bytes SI</t> <li>3 bytes SPI</li>
<t>4 bytes Reserved (SHOULD be set to zero and ignored)</t> <li>1 byte SI</li>
</list></t> <li>4 bytes Reserved (<bcp14>SHOULD</bcp14> be set to zero and ignored
)</li>
<t>If the SI in this encoding is not part of the SFPR indicated by the SP </ul>
I in this <t>If the SI in this encoding is not part of the SFPR indicated by the S
encoding, then this is an explicit error that SHOULD be detected by th PI in this
e SFF when it encoding, then this is an explicit error that <bcp14>SHOULD</bcp14> be
parses the SFPR. The SFPR SHOULD NOT cause any forwarding state to be detected by the SFF when it
installed in parses the SFPR. The SFPR <bcp14>SHOULD NOT</bcp14> cause any forward
the SFF and packets received with the SPI that indicates this SFPR SHO ing state to be installed in
ULD be silently the SFF, and packets received with the SPI that indicates this SFPR <b
cp14>SHOULD</bcp14> be silently
discarded.</t> discarded.</t>
<t>If the SPI in this encoding is unknown, the SFF <bcp14>SHOULD NOT</bc
<t>If the SPI in this encoding is unknown, the SFF SHOULD NOT install any p14> install any forwarding state
forwarding state for this SFPR but <bcp14>MAY</bcp14> hold the SFPR pending receipt of
for this SFPR, but MAY hold the SFPR pending receipt of another SFPR t another SFPR that does use the
hat does use the
encoded SPI.</t> encoded SPI.</t>
<t>If the SPI matches the current SPI for the path, this is a loop or jum <t>If the SPI matches the current SPI for the path, this is a loop or ju
p. In this case, mp. In this case,
if the SI is greater than to the current SI it is a loop. If the SPI if the SI is greater than or equal to the current SI, it is a loop. I
matches and the SI f the SPI matches and the SI
is less than the next SI, it is a jump.</t> is less than the next SI, it is a jump.</t>
<t>If the SPI indicates another path, this is a branch, and the SI indic
<t>If the SPI indicates another path, this is a branch and the SI indicat ates the point at
es the point at
which to enter that path.</t> which to enter that path.</t>
<t>The Change Sequence SFT is just another SFT that may appear in a set
of SFI/SFT tuples
within an SI and is selected as described in <xref target="selection"
format="default"/>.</t>
<t>Note that special-purpose SFTs <bcp14>MUST NOT</bcp14> be advertised
in SFIRs. If such an SFIR is
received, it <bcp14>SHOULD</bcp14> be ignored.</t>
</section>
<section anchor="implications" numbered="true" toc="default">
<name>Implications for Forwarding State</name>
<t>Support for looping and jumping requires that the SFF has forwarding
state established
to an SFF that provides access to an instance of the appropriate SF.
<t>The Change Sequence SFT is just another SFT that may appear in a set o This means
f SFI/SFT tuples that the SFF must have seen the relevant SFIR advertisements and mush
within an SI and is selected as described in <xref target="selection" have known that it needed to
/>.</t> create the forwarding state. This is a matter of local configuration
and implementation;
<t>Note that Special Purpose SFTs MUST NOT be advertised in SFIRs. If su
ch an SFIR is
received it SHOULD be ignored.</t>
</section>
<section anchor="implications" title="Implications for Forwarding State">
<t>Support for looping and jumping requires that the SFF has forwarding s
tate established
to an SFF that provides access to an instance of the appropriate SF.
This means
that the SFF must have seen the relevant SFIR advertisements and known
that it needed to
create the forwarding state. This is a matter of local configuration
and implementation:
for example, an implementation could be configured to install forwardi ng state for specific for example, an implementation could be configured to install forwardi ng state for specific
looping/jumping.</t> looping/jumping.</t>
<t>Support for branching requires that the SFF has forwarding state esta
<t>Support for branching requires that the SFF has forwarding state estab blished to an SFF that
lished to an SFF that
provides access to an instance of the appropriate entry SF on the othe r SFP. This means provides access to an instance of the appropriate entry SF on the othe r SFP. This means
that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it that the SFF must have seen the relevant SFIR and SFPR advertisements and known that it
needed to create the forwarding state. This is a matter of local conf iguration and needed to create the forwarding state. This is a matter of local conf iguration and
implementation: for example, an implementation could be configured to install forwarding implementation; for example, an implementation could be configured to install forwarding
state for specific branching (identified by SPI and SI).</t> state for specific branching (identified by SPI and SI).</t>
</section>
</section> </section>
<section anchor="advanced" numbered="true" toc="default">
</section> <name>Advanced Topics</name>
<t>This section highlights several advanced topics introduced elsewhere in
<section anchor="advanced" title="Advanced Topics"> this document.</t>
<section anchor="correlation" numbered="true" toc="default">
<t>This section highlights several advanced topics introduced elsewhere in t <name>Correlating Service Function Path Instances</name>
his document.</t> <t>It is often useful to create bidirectional SFPs to enable packet
flows to traverse the same
<section anchor="correlation" title="Correlating Service Function Path Insta
nces">
<t>It is often useful to create bidirectional SFPs to enable packet flows
to traverse the same
set of SFs, but in the reverse order. However, packets on SFPs in the data plane (per set of SFs, but in the reverse order. However, packets on SFPs in the data plane (per
<xref target="RFC8300" />) do not contain a direction indicator, so eac h direction <xref target="RFC8300" format="default"/>) do not contain a direction i ndicator, so each direction
must use a different SPI.</t> must use a different SPI.</t>
<t>As described in <xref target="assoctlv" format="default"/>, an SFPR c
<t>As described in <xref target="assoctlv" /> an SFPR can contain one or m an contain one or more correlators
ore correlators encoded in Association TLVs.
encoded in Association TLVs. If the Association Type indicates "Bidire If the Association Type indicates "Bidirectional SFP", then
ctional SFP" then the SFP advertised in the SFPR is one direction of a bidirectional pair
the SFP advertised in the SFPR is one direction of a bidirectional pair of SFPs, where the
of SFPs where the other in the pair is advertised in the SFPR with RD as carried in the "
other in the pair is advertised in the SFPR with RD as carried in the A Associated SFPR-RD"
ssociated SFPR-RD field of the Association TLV. The SPI carried in the "Associated SPI"
field of the Association TLV. The SPI carried in the Associated SPI fi field of the
eld of the
Association TLV provides a cross-check against the SPI advertised in th e SFPR with Association TLV provides a cross-check against the SPI advertised in th e SFPR with
RD as carried in the Associated SFPR-RD field of the Association TLV.</ RD as carried in the "Associated SFPR-RD" field of the Association TLV.
t> </t>
<t>As noted in <xref target="assoctlv" format="default"/>, when SFPRs re
<t>As noted in <xref target="assoctlv" />, when SFPRs reference each other ference each other, one SFPR advertisement
, one SFPR advertisement
will be received before the other. Therefore, processing of an associa tion will require will be received before the other. Therefore, processing of an associa tion will require
that the first SFPR is not rejected simply because the Associated SFPR- that the first SFPR not be rejected simply because the Associated SFPR-
RD it carries is RD it carries is
unknown. However, the SFP defined by the first SFPR is valid and SHOUL unknown. However, the SFP defined by the first SFPR is valid and <bcp1
D be available for 4>SHOULD</bcp14> be available for
use as a unidirectional SFP even in the absence of an advertisement of use as a unidirectional SFP, even in the absence of an advertisement of
its partner.</t> its partner.</t>
<t>Furthermore, in error cases where SFPR-a associates with SFPR-b, but
<t>Furthermore, in error cases where SFPR-a associates with SFPR-b, but SF SFPR-b associates
PR-b associates
with SFPR-c such that a bidirectional pair of SFPs cannot be formed, th e individual SFPs with SFPR-c such that a bidirectional pair of SFPs cannot be formed, th e individual SFPs
are still valid and SHOULD be available for use as unidirectional SFPs. are still valid and <bcp14>SHOULD</bcp14> be available for use as unidi
An implementation rectional SFPs. An implementation
SHOULD log this situation because it represents a Controller error.</t> <bcp14>SHOULD</bcp14> log this situation, because it represents a contr
oller error.</t>
<t>Usage of a bidirectional SFP may be programmed into the Classifiers by <t>Usage of a bidirectional SFP may be programmed into the classifiers b
the Controller. y the controller.
Alternatively, a Classifier may look at incoming packets on a bidirecti Alternatively, a classifier may look at incoming packets on a bidirecti
onal packet flow, onal packet flow,
extract the SPI from the received NSH, and look up the SFPR to find the extract the SPI from the received NSH, and look up the SFPR to find the
reverse direction reverse-direction
SFP to use when it sends packets.</t> SFP to use when it sends packets.</t>
<t>See <xref target="example" format="default"/> for an example of how t
<t>See <xref target="example" /> for an example of how this works.</t> his works.</t>
</section>
</section> <section anchor="stateful" numbered="true" toc="default">
<name>Considerations for Stateful Service Functions</name>
<section anchor="stateful" title="Considerations for Stateful Service Functi <t>Some service functions are stateful. That means that they build and
ons"> maintain state derived
from configuration or the packet flows that they handle. In such cases
<t>Some service functions are stateful. That means that they build and ma , it can be
intain state derived
from configuration or from the packet flows that they handle. In such
cases it can be
important or necessary that all packets from a flow continue to travers e the same instance important or necessary that all packets from a flow continue to travers e the same instance
of a service function so that the state can be leveraged and does not n eed to be regenerated.</t> of a service function so that the state can be leveraged and does not n eed to be regenerated.</t>
<t>In the case of bidirectional SFPs, it may be necessary to traverse th
<t>In the case of bidirectional SFPs, it may be necessary to traverse the e same instances of a
same instances of a
stateful service function in both directions. A firewall is a good exa mple of such a service stateful service function in both directions. A firewall is a good exa mple of such a service
function.</t> function.</t>
<t>This issue becomes a concern where there are multiple parallel instan
<t>This issue becomes a concern where there are multiple parallel instance ces of a service function
s of a service function
and a determination of which one to use could normally be left to the S FF as a load-balancing and a determination of which one to use could normally be left to the S FF as a load-balancing
or local policy choice.</t> or local-policy choice.</t>
<t>For the forward-direction SFP, the concern is that the same choice of
<t>For the forward direction SFP, the concern is that the same choice of s SF is made
ervice function is made
for all packets of a flow under normal network conditions. It may be p ossible to guarantee for all packets of a flow under normal network conditions. It may be p ossible to guarantee
that the load balancing functions applied in the SFFs are stable and re that the load-balancing functions applied in the SFFs are stable and re
peatable, but a Controller peatable, but a controller
that constructs SFPs might not want to trust to this. The Controller c that constructs SFPs might not want to trust to this. The controller c
an, in these cases, build an, in these cases, build
a number of more specific SFPs each traversing a specific instance of t a number of more specific SFPs, each traversing a specific instance of
he stateful SFs. In this the stateful SFs. In this
case, the load balancing choice can be left up to the Classifier. Thus case, the load-balancing choice can be left up to the classifier. Thus
the Classifier selects , the classifier selects
which instance of a stateful SF is used by a particular flow by selecti ng the SFP that the flow which instance of a stateful SF is used by a particular flow by selecti ng the SFP that the flow
uses.</t> uses.</t>
<t>For bidirectional SFPs where the same instance of a stateful SF must
<t>For bidirectional SFPs where the same instance of a stateful SF must be be traversed in both
traversed in both directions, it is not enough to leave the choice of SFI as a local choi
directions, it is not enough to leave the choice of service function in ce,
stance as a local choice even if the load balancing is stable, because coordination would be req
even if the load balancing is stable because coordination would be requ uired between the decision
ired between the decision points in the forward and reverse directions, and this may be hard to a
points in the forward and reverse directions and this may be hard to ac chieve in all cases except
hieve in all cases except
where it is the same SFF that makes the choice in both directions.</t> where it is the same SFF that makes the choice in both directions.</t>
<t>Note that this approach necessarily increases the amount of SFP state
<t>Note that this approach necessarily increases the amount of SFP state i in the network (i.e., there
n the network (i.e., there
are more SFPs). It is possible to mitigate this effect by careful cons truction of SFPs built are more SFPs). It is possible to mitigate this effect by careful cons truction of SFPs built
from a concatenation of other SFPs.</t> from a concatenation of other SFPs.</t>
<t><xref target="examplestate" format="default"/> includes some simple e
<t><xref target="examplestate" /> includes some simple examples of SFPs fo xamples of SFPs for stateful SFs.</t>
r stateful service </section>
functions.</t> <section anchor="private" numbered="true" toc="default">
<name>VPN Considerations and Private Service Functions</name>
</section> <t>Likely deployments include reserving specific instances of SFs for sp
ecific
<section anchor="private" title="VPN Considerations and Private Service Func customers or allowing customers to deploy their own SFs within the netw
tions"> ork.
Building SFs in such environments requires that suitable identifiers be
<t>Likely deployments include reserving specific instances of Service Func used
tions for specific
customers or allowing customers to deploy their own Service Functions w
ithin the network.
Building Service Functions in such environments requires that suitable
identifiers are used
to ensure that SFFs distinguish which SFIs can be used and which cannot .</t> to ensure that SFFs distinguish which SFIs can be used and which cannot .</t>
<t>This problem is similar to how VPNs are supported and is solved in a si <t>This problem is similar to a problem in the way that VPNs are support
milar way. The RT ed and is solved in a similar way. The "RT"
field is used to indicate a set of Service Functions from which all cho field is used to indicate a set of SFs from which all choices must be m
ices must be made.</t> ade.</t>
</section>
</section> <section anchor="fspecclassy" numbered="true" toc="default">
<name>Flow Specification for SFC Classifiers</name>
<section anchor="fspecclassy" title="Flow Specification for SFC Classifiers" <t><xref target="RFC8955" format="default"/> defines a set of BGP
>
<t><xref target="I-D.ietf-idr-rfc5575bis" /> defines a set of BGP
routes that can be used to identify the packets in a given flow using f ields in the header of routes that can be used to identify the packets in a given flow using f ields in the header of
each packet, and a set of actions, encoded as extended communities, tha t can be used to each packet, and a set of actions -- encoded as Extended Communities -- that can be used to
disposition those packets. This document enables the use of these mech anisms by SFC disposition those packets. This document enables the use of these mech anisms by SFC
Classifiers by defining a new action extended community called "Flow Sp classifiers by defining a new action Extended Community called "Flow Sp
ecification for SFC Classifiers" ecification for SFC Classifiers",
identified by the value TBD4. Note that implementation of this section identified by the value 0x0d. Note that implementation of this section
of this specification will be of this specification will be
Controllers or Classifiers communicating with each other directly for t controllers or classifiers communicating with each other directly for t
he purpose of instructing the he purpose of instructing the
Classifier how to place packets onto an SFP. In order that the impleme classifier how to place packets onto an SFP. So that the implementatio
ntation of Classifiers can be n of classifiers can be
kept simple and to avoid the confusion between the purpose of different kept simple, and to avoid the confusion between the purposes of differe
extended communities, a nt Extended Communities, a
Controller MUST NOT include other action extended communities at the sa controller <bcp14>MUST NOT</bcp14> include other action Extended Commun
me time as a "Flow Specification ities at the same time as a "Flow Specification
for SFC Classifiers" extended community: a "Flow Specification for SFC for SFC Classifiers" Extended Community. A "Flow Specification for SFC
Classifiers" Traffic Filtering Action Classifiers" Traffic Filtering Action
Extended Community advertised with any other Traffic Filtering Action E Extended Community advertised with any other Traffic Filtering Action E
xtended Community MUST be treated as xtended Community <bcp14>MUST</bcp14> be treated as
malformed in line with <xref target="I-D.ietf-idr-rfc5575bis" /> and re malformed in line with <xref target="RFC8955" format="default"/> and re
sult in the Flow Specification sult in the flow-specification
UPDATE message being handled as treat-as-withdraw according to <xref ta UPDATE message being handled as "treat-as-withdraw", according to
rget="RFC7606" /> Section 2.</t> <xref target="RFC7606" section="2" sectionFormat="comma"/>.</t>
<t>To put the flow specification into context, when multiple service fun
<t>To put the Flow Specification into context when multiple SFC overlays a ction chaining overlays are present in one
re present in one network, each FlowSpec update <bcp14>MUST</bcp14> be tagged with the ro
network, each FlowSpec update MUST be tagged with the route target of t ute target of the overlay or VPN
he overlay or VPN
network for which it is intended.</t> network for which it is intended.</t>
<t>This Extended Community is encoded as an 8-octet value, as shown in <
<t>This extended community is encoded as an 8-octet value, as shown in <xr xref target="fspecclassyfig" format="default"/>.</t>
ef target="fspecclassyfig"/>.</t> <figure anchor="fspecclassyfig">
<name>The Format of the Flow Specification for SFC Classifiers Extende
<figure anchor="fspecclassyfig" title="The Format of the Flow Specificatio d Community</name>
n for SFC Classifiers Extended Community"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
1 2 3 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=0x80 | Sub-Type=TBD4 | SPI | | Type=0x80 | Sub-Type=0x0d | SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (cont.) | SI | SFT | | SPI (cont.) | SI | SFT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The Extended Community contains the Service Path Identifier (SPI), Se
rvice Index (SI), and
<t>The extended community contains the Service Path Identifier (SPI), Serv Service Function Type (SFT), as defined elsewhere in this document. Th
ice Index (SI), and us, each action extended
Service Function Type (SFT) as defined elsewhere in this document. Thu community defines the entry point (not necessarily the first hop) into
s, each action extended a specific SFP. This allows, for example, different flows to enter the same SFP
community defines the entry point (not necessarily the first hop) into at different points.</t>
a specific service <t>Note that, according to <xref target="RFC8955" format="default"/>, a
function path. This allows, for example, different flows to enter the given flow-specification
same service function update may include multiple of these action Extended Communities. If a
path at different points.</t> given action extended
community does not contain an installed SFPR with the specified {SPI, S
<t>Note that according to <xref target="I-D.ietf-idr-rfc5575bis" /> a give I, SFT}, it <bcp14>MUST NOT</bcp14> be
n Flow Specification
update may include multiple of these action extended communities. If a
given action extended
community does not contain an installed SFPR with the specified {SPI, S
I, SFT} it MUST NOT be
used for dispositioning the packets of the specified flow.</t> used for dispositioning the packets of the specified flow.</t>
<t>The normal case of packet classification for service function chainin
<t>The normal case of packet classification for SFC will see a packet ente g will see a packet enter the SFP at its first
r the SFP at its first hop. In this case, the SI in the Extended Community is superfluous, an
hop. In this case the SI in the extended community is superfluous and d the SFT may also be
the SFT may also be unnecessary. To allow these cases to be handled, a special meaning is
unnecessary. To allow these cases to be handled, a special meaning is assigned to an SI of zero (not a valid value) and an SFT of zero (a reserved val
assigned to a Service ue in the registry -- see
Index of zero (not a valid value) and an SFT of zero (a reserved value <xref target="SFTreg" format="default"/>).
in the registry - see </t>
<xref target="SFTreg" />). <ul spacing="normal">
<list style="symbols"> <li>If an SFC Classifiers Extended Community is received with SI = 0,
<t>If an SFC Classifiers Extended Community is received with SI = 0 t then it means that the
hen it means that the first hop of the SFP indicated by the SPI <bcp14>MUST</bcp14> be u
first hop of the SFP indicated by the SPI MUST be used.</t> sed.</li>
<t>If an SFC Classifiers Extended Community is received with SFT = 0 <li>
then there are two <t>If an SFC Classifiers Extended Community is received with SFT = 0
sub-cases: , then there are two
<list style="symbols"> subcases:
<t>If there is a choice of SFT in the hop indicated by the valu </t>
e of the SI (including <ul spacing="normal">
SI = 0) then SFT = 0 means there is a free choice according <li>If there is a choice of SFT in the hop indicated by the value
to local policy of of the SI (including
which SFT to use).</t> SI = 0), then SFT = 0 means there is a free choice of
<t>If there is no choice of SFT in the hop indicated by the val which SFT to use, according to local policy).</li>
ue of SI, then SFT = 0 <li>If there is no choice of SFT in the hop indicated by the value
means that the value of the SFT at that hop as indicated in of SI, then SFT = 0
the SFPR for the means that the value of the SFT at that hop, as indicated in
indicated SPI MUST be used.</t> the SFPR for the
</list></t> indicated SPI, <bcp14>MUST</bcp14> be used.</li>
</list></t> </ul>
</li>
<t>One of the filters that the Flow Specification may describe is the VPN </ul>
to which the traffic belongs. <t>One of the filters that the flow specification may describe is the VP
N to which the traffic belongs.
Additionally, as noted above, to put the indicated SPI into context whe n multiple SFC overlays are Additionally, as noted above, to put the indicated SPI into context whe n multiple SFC overlays are
present in one network, each FlowSpec update MUST be tagged with the ro ute target of the present in one network, each FlowSpec update <bcp14>MUST</bcp14> be tag ged with the route target of the
overlay or VPN network for which it is intended.</t> overlay or VPN network for which it is intended.</t>
<t>Note that future extensions might be made to the Flow Specification f
<t>Note that future extensions might be made to the Flow Specification for or SFC Classifiers Extended Community
SFC Classifiers Extended Community to provide instruction to the classifier about what metadata to add to
to provide instruction to the Classifier about what metadata to add to packets that it classifies
packets that it classifies for forwarding on a specific SFP; however, that is outside the scope of
for forwarding on a specific SFP, but that is outside the scope of this this document.</t>
document.</t> </section>
<section anchor="representation" numbered="true" toc="default">
</section> <name>Choice of Data Plane SPI/SI Representation</name>
<t>This document ties together the control and data planes of a service
<section anchor="representation" title="Choice of Data Plane SPI/SI Represen function chaining overlay network through the use
tation"> of the SPI/SI that is nominally carried in the NSH of a given packet.
However, in order to handle
<t>This document ties together the control and data planes of an SFC overl
ay network through the use
of the SPI/SI which is nominally carried in the NSH of a given packet.
However, in order to handle
situations in which the NSH is not ubiquitously deployed, it is also po ssible to use alternative situations in which the NSH is not ubiquitously deployed, it is also po ssible to use alternative
data plane representations of the SPI/SI by carrying the identical sema data plane representations of the SPI/SI by carrying the identical sema
ntics in other protocol fields ntics in other protocol fields,
such as MPLS labels <xref target="RFC8595" />.</t> such as MPLS labels <xref target="RFC8595" format="default"/>.</t>
<t>This document defines a new Sub-TLV for the tunnel encapsulation attr
<t>This document defines a new sub-TLV for the Tunnel Encapsulation attrib ibute <xref target="RFC9012" format="default"/>,
ute <xref target="I-D.ietf-idr-tunnel-encaps" />, the SPI/SI Representation Sub-TLV of type 16. This Sub-TLV <bcp14>MAY<
the SPI/SI Representation sub-TLV of type TBD5. This sub-TLV MAY be pr /bcp14> be present in each Tunnel TLV contained
esent in each Tunnel TLV contained in a tunnel encapsulation attribute when the attribute is carried by an
in a Tunnel Encapsulation attribute when the attribute is carried by an SFIR. The "Value" field of this
SFIR. The value field of this Sub-TLV is a two-octet field of flags numbered counting from the most s
sub-TLV is a two octet field of flags numbered counting from the the mo ignificant bit, each of which
st significant bit, each of which
describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets describes how the originating SFF expects to see the SPI/SI represented in the data plane for packets
carried in the tunnels described by the Tunnel TLV.</t> carried in the tunnels described by the Tunnel TLV.</t>
<t>The following bits are defined by this document and are tracked in an
<t>The following bits are defined by this document and are tracked in an I IANA registry described in
ANA registry described in <xref target="IANAbits" format="default"/>:
<xref target="IANAbits" />: </t>
<list style="hanging"> <dl newline="false" spacing="normal">
<t hangText="Bit TBD9:">If this bit is set the NSH is to be used to c <dt>Bit 0:</dt>
arry the SPI/SI in the data plane.</t> <dd>If this bit is set, the NSH is to be used to carry the SPI/SI in t
<t hangText="Bit TBD10:">If this bit is set two labels in an MPLS lab he data plane.</dd>
el stack are to be used as described in <dt>Bit 1:</dt>
<xref target="MPLS-NSH" />.</t> <dd>If this bit is set, two labels in an MPLS label stack are to be us
</list></t> ed as described in
<xref target="MPLS-NSH" format="default"/>.</dd>
<t>If a given Tunnel TLV does not contain an SPI/SI Representation sub-TLV </dl>
then it MUST be processed as if <t>If a given Tunnel TLV does not contain an SPI/SI Representation Sub-T
such a sub-TLV is present with Bit TBD9 set and no other bits set. Tha LV, then it <bcp14>MUST</bcp14> be processed as if
t is, the absence of the sub-TLV such a Sub-TLV is present with Bit 0 set and no other bits set. That i
SHALL be interpreted to mean that the NSH is to be used.</t> s, the absence of the Sub-TLV
<bcp14>SHALL</bcp14> be interpreted to mean that the NSH is to be used.
<t>If a given Tunnel TLV contains an SPI/SI Representation sub-TLV with va </t>
lue field that has no flag set then <t>If a given Tunnel TLV contains an SPI/SI Representation Sub-TLV
the tunnel indicated by the Tunnel TLV MUST NOT be used for forwarding with a "Value" field that has no flag set, then
SFC packets. If a given Tunnel TLV the tunnel indicated by the Tunnel TLV <bcp14>MUST NOT</bcp14> be used
contains an SPI/SI Representation sub-TLV with both bit TBD9 and bit TB for forwarding SFC packets. If a given Tunnel TLV
D10 set then the tunnel indicated by the contains an SPI/SI Representation Sub-TLV with both bit 0 and bit 1 set
Tunnel TLV MUST NOT be used for forwarding SFC packets. The meaning an , then the tunnel indicated by the
d rules for presence of other bits Tunnel TLV <bcp14>MUST NOT</bcp14> be used for forwarding SFC
is to be defined in future documents, but implementations of this speci packets. The meaning and rules for the presence of other bits
fication MUST set other bits to is to be defined in future documents, but implementations of this speci
fication <bcp14>MUST</bcp14> set other bits to
zero and ignore them on receipt.</t> zero and ignore them on receipt.</t>
<t>If a given Tunnel TLV contains more than one SPI/SI Representation Su
<t>If a given Tunnel TLV contains more than one SPI/SI Representation sub- b-TLV, then the first one <bcp14>MUST</bcp14> be
TLV then the first one MUST be considered and subsequent instances <bcp14>MUST</bcp14> be ignored.</t>
considered and subsequent instances MUST be ignored.</t> <t>Note that the MPLS representation of the logical NSH may be used even
if the tunnel is not an MPLS tunnel.
<t>Note that the MPLS representation of the logical NSH may be used even i
f the tunnel is not an MPLS tunnel.
Conversely, MPLS tunnels may be used to carry other encodings of the lo gical NSH (specifically, the NSH Conversely, MPLS tunnels may be used to carry other encodings of the lo gical NSH (specifically, the NSH
itself). It is a requirement that both ends of a tunnel over the under lay network know that the tunnel is itself). It is a requirement that both ends of a tunnel over the under lay network know that the tunnel is
used for SFC and know what form of NSH representation is used. The sig naling mechanism described here used for service function chaining and know what form of NSH representa tion is used. The signaling mechanism described here
allows coordination of this information.</t> allows coordination of this information.</t>
<section anchor="MPLS-NSH" numbered="true" toc="default">
<section anchor="MPLS-NSH" title="MPLS Representation of the SPI/SI"> <name>MPLS Representation of the SPI/SI</name>
<t>If bit 1 is set in the SPI/SI Representation Sub-TLV, then labels i
<t>If bit TBD10 is set in the in the SPI/SI Representation sub-TLV then n the MPLS label stack are
labels in the MPLS label stack are
used to indicate SFC forwarding and processing instructions to achie ve the semantics of a logical NSH. used to indicate SFC forwarding and processing instructions to achie ve the semantics of a logical NSH.
The label stack is encoded as shown in <xref target="RFC8595" />.</t The label stack is encoded as shown in <xref target="RFC8595" format
> ="default"/>.</t>
</section>
</section> </section>
<section anchor="swapOp" numbered="true" toc="default">
</section> <name>MPLS Label Swapping/Stacking Operation</name>
<t>When a classifier constructs an MPLS label stack for an SFP, it start
<section anchor="swapOp" title="MPLS Label Swapping/Stacking Operation"> s with that SFP's last hop. If the
<t>When a Classifier constructs an MPLS label stack for an SFP it starts w
ith that SFP&apos;s last hop. If the
last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the last hop requires an {SPI, SI} label pair for label swapping, it pushes the SI (set to the SI value of the
last hop) and the SFP&apos;s SPI onto the MPLS label stack. If the las last hop) and the SFP's SPI onto the MPLS label stack. If the last hop
t hop requires a {context label, SFI requires a {context label, SFI
label} label pair for label stacking it selects a specific SFIR and pus label} label pair for label stacking, it selects a specific SFIR and pu
hes that SFIR&apos;s SFI label and shes that SFIR's SFI label and
context label onto the MPLS label stack.</t> context label onto the MPLS label stack.</t>
<t>The classifier then moves sequentially back through the SFP one hop a
<t>The Classifier then moves sequentially back through the SFP one hop at t a time. For each hop, if the hop
a time. For each hop, if the hop requires an {SPI, SI} and there is an {SPI, SI} at the top of the MPLS
requires an {SPI, SI]} and there is an {SPI, SI} at the top of the MPLS label stack, the SI is set to the
label stack, the SI is set to the
SI value of the current hop. If there is not an {SPI, SI} at the top o f the MPLS label stack, it pushes SI value of the current hop. If there is not an {SPI, SI} at the top o f the MPLS label stack, it pushes
the SI (set to the SI value of the current hop) and the SFP&apos;s SPI the SI (set to the SI value of the current hop) and the SFP's SPI onto
onto the MPLS label stack.</t> the MPLS label stack.</t>
<t>If the hop requires a {context label, SFI label}, it selects a specif
<t>If the hop requires a {context label, SFI label}, it selects a specific ic SFIR and pushes that SFIR's
SFIR and pushes that SFIR&apos;s
SFI label and context label onto the MPLS label stack.</t> SFI label and context label onto the MPLS label stack.</t>
</section>
<section anchor="mpls-encaps" numbered="true" toc="default">
<name>Support for MPLS-Encapsulated NSH Packets</name>
<t><xref target="RFC8596" format="default"/> describes how to transport
SFC packets using the NSH
over an MPLS transport network.
</section> Signaling that this approach is in use is supported by this document
as follows:</t>
<section anchor="mpls-encaps" title="Support for MPLS-Encapsulated NSH Packe <ul spacing="normal">
ts"> <li>A "BGP Tunnel Encapsulation Attribute" Sub-TLV is included with the
codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel
<t><xref target="RFC8596" /> describes how to transport SFC packets using Encapsulation Attribute Sub-TLVs" registry defined in
the NSH <xref target="RFC9012" format="default"/>.</li>
over an MPLS transport network. Signaling MPLS encapsulation of SFC p
ackets using the NSH is also
supported by this document by using the "BGP Tunnel Encapsulation Attr
ibute Sub-TLV" with the
codepoint 10 (representing "MPLS Label Stack") from the "BGP Tunnel En
capsulation Attribute Sub-TLVs"
registry defined in <xref target="I-D.ietf-idr-tunnel-encaps" />, and
also using the "SFP Traversal
With MPLS Label Stack TLV" and the "SPI/SI Representation sub-TLV" wit
h bit TBD9 set and bit TBD10 cleared.</t>
<t>In this case the MPLS label stack constructed by the SFF to forward a <li>An "SFP Traversal With MPLS Label Stack" TLV is included containing
packet to the next SFF on the an "SPI/SI Representation" Sub-TLV with bit 0 set and bit 1 cleared.</li></u
SFP will consist of the labels needed to reach that SFF, and if label l>
stacking is used it will also <t>In this case, the MPLS label stack constructed by the SFF to forward
include the labels advertised in the MPLS Label Stack sub-TLV and the a packet to the next SFF on the
labels remaining in the stack SFP will consist of the labels needed to reach that SFF, and if label
stacking is used, it will also
include the labels advertised in the MPLS Label Stack Sub-TLV and the
labels remaining in the stack
needed to traverse the remainder of the SFP.</t> needed to traverse the remainder of the SFP.</t>
</section>
</section> </section>
<section anchor="example" numbered="true" toc="default">
</section> <name>Examples</name>
<t>Most of the examples in this section use IPv4 addressing. But there is
<section anchor="example" title="Examples"> nothing special about
<t>Most of the examples in this section use IPv4 addressing. But there is n
othing special about
IPv4 in the mechanisms described in this document, and they are equally a pplicable to IPv6. A IPv4 in the mechanisms described in this document, and they are equally a pplicable to IPv6. A
few examples using IPv6 addressing are provided in <xref target="v6sample s" />.</t> few examples using IPv6 addressing are provided in <xref target="v6sample s" format="default"/>.</t>
<t>Assume we have a service function overlay network with four SFFs (SFF1, S FF3, SFF3, and SFF4). <t>Assume we have a service function overlay network with four SFFs (SFF1, SFF2, SFF3, and SFF4).
The SFFs have addresses in the underlay network as follows:</t> The SFFs have addresses in the underlay network as follows:</t>
<figure> <sourcecode><![CDATA[
<artwork>
<![CDATA[
SFF1 192.0.2.1 SFF1 192.0.2.1
SFF2 192.0.2.2 SFF2 192.0.2.2
SFF3 192.0.2.3 SFF3 192.0.2.3
SFF4 192.0.2.4 SFF4 192.0.2.4
]]> ]]></sourcecode>
</artwork> <t>Each SFF provides access to some SFIs from the four SFTs, SFT=41, SFT=4
</figure> 2,
SFT=43, and SFT=44, as follows:</t>
<t>Each SFF provides access to some SFIs from the four Service Function Type <sourcecode><![CDATA[
s SFT=41, SFT=42,
SFT=43, and SFT=44 as follows:</t>
<figure>
<artwork>
<![CDATA[
SFF1 SFT=41 and SFT=42 SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43 SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44 SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44 SFF4 SFT=43 and SFT=44
]]> ]]></sourcecode>
</artwork> <t>The service function network also contains a controller with address 19
</figure> 8.51.100.1.</t>
<t>This example service function overlay network is shown in <xref target=
<t>The service function network also contains a Controller with address 198. "examplefig" format="default"/>.</t>
51.100.1.</t> <figure anchor="examplefig">
<name>Example Service Function Overlay Network</name>
<t>This example service function overlay network is shown in <xref target="e <artwork name="" type="" align="left" alt=""><![CDATA[
xamplefig" />.</t>
<figure anchor="examplefig" title="Example Service Function Overlay Netwo
rk">
<artwork>
<![CDATA[
-------------- --------------
| Controller | | Controller |
| 198.51.100.1 | ------ ------ ------ ------ | 198.51.100.1 | ------ ------ ------ ------
-------------- | SFI | | SFI | | SFI | | SFI | -------------- | SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43| |SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------ ------ ------ ------ ------
\ / \ / \ / \ /
--------- --------- --------- ---------
---------- | SFF1 | | SFF2 | ---------- | SFF1 | | SFF2 |
Packet --> | | |192.0.2.1| |192.0.2.2| Packet --> | | |192.0.2.1| |192.0.2.2|
skipping to change at line 1689 skipping to change at line 1474
| | --> | | -->
---------- --------- --------- ---------- --------- ---------
| SFF3 | | SFF4 | | SFF3 | | SFF4 |
|192.0.2.3| |192.0.2.4| |192.0.2.3| |192.0.2.4|
--------- --------- --------- ---------
/ \ / \ / \ / \
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44| |SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------ ------ ------ ------ ------
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The SFFs advertise routes to the SFIs they support. These advertisemen
ts
<t>The SFFs advertise routes to the SFIs they support. These advertisements contain RDs that are set according to the network operator's
contain Route Distinguishers that are set according to the network operat configuration model. In all of these IPv4 examples, we use RDs of Type 1
or&apos;s such that the
configuration model. In all of these IPv4 examples we use RDs of type 1
such that the
available six octets are partitioned as four octets for the IPv4 address of the advertising available six octets are partitioned as four octets for the IPv4 address of the advertising
SFF, and two octets that are a local index of the SFI. This scheme is ch osen purely for SFF, and two octets that are a local index of the SFI. This scheme is ch osen purely for
convenience of documentation, and an operator is totally free to use any other scheme so convenience of documentation, and an operator is totally free to use any other scheme so
long as it conforms to the definitions of SFIR and SFPR in <xref target=" long as it conforms to the definitions of SFIR and SFPR in Sections
sfiRoutes" /> and <xref target="sfiRoutes" format="counter"/> and
<xref target="sfpRoutes" />.</t> <xref target="sfpRoutes" format="counter"/>.</t>
<t>Thus, we see the following SFIRs advertised:</t>
<t>Thus we see the following SFIRs advertised:</t> <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
RD = 192.0.2.1/1, SFT = 41 RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42 RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41 RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43 RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42 RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44 RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43 RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44 RD = 192.0.2.4/6, SFT = 44
]]> ]]></sourcecode>
</artwork> <t>Note that the addressing used for communicating between SFFs is taken
</figure> from the tunnel encapsulation attribute of the SFIR and not from the SFIR
-RD.</t>
<t>Note that the addressing used for communicating between SFFs is taken <section anchor="exampleexplicit" numbered="true" toc="default">
from the Tunnel Encapsulation attribute of the SFIR and not from the SFIR <name>Example Explicit SFP with No Choices</name>
-RD.</t> <t>Consider the following SFPR.</t>
<sourcecode><![CDATA[
<section anchor="exampleexplicit" title="Example Explicit SFP With No Choice
s" >
<t>Consider the following SFPR.</t>
<figure>
<artwork>
<![CDATA[
SFP1: RD = 198.51.100.1/101, SPI = 15, SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
]]> ]]></sourcecode>
</artwork> <t>The SFP consists of an SF of Type 41 located at SFF1, followed by an
</figure> SF
of Type 43 located at SFF2. This path is fully explicit, and each SFF
<t>The Service Function Path consists of an SF of type 41 located at SFF1 is
followed by an SF
of type 43 located at SFF2. This path is fully explicit and each SFF
is
offered no choice in forwarding packets along the path.</t> offered no choice in forwarding packets along the path.</t>
<t>SFF1 will receive packets on the path from the classifier and will id
<t>SFF1 will receive packets on the path from the Classifier and will ide entify the path
ntify the path from the SPI (15). The initial SI will be 255, and so SFF1 will deliv
from the SPI (15). The initial SI will be 255 and so SFF1 will delive er the packets to the
r the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be decr
<t>When the packets are returned to SFF1 by the SFI the SI will be decre eased to 250 for the next hop.
ased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next-hop
SFF1 has no flexibility in the choice of SFF to support the next hop SFI and will forward
SFI and will forward the packet to SFF2, which will send the packets to the SFI that suppo
the packet to SFF2 which will send the packets to the SFI that suppor rts SFT 43 before
ts SFT 43 before
forwarding the packets to their destinations.</t> forwarding the packets to their destinations.</t>
</section>
</section> <section anchor="examplechoice" numbered="true" toc="default">
<name>Example SFP with Choice of SFIs</name>
<section anchor="examplechoice" title="Example SFP With Choice of SFIs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP2: RD = 198.51.100.1/102, SPI = 16, SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2, [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ] RD = 192.0.2.4/5 } ]
]]> ]]></sourcecode>
</artwork> <t>In this example, the path also consists of an SF of Type 41 located a
</figure> t SFF1, and this is
followed by an SF of Type 43. However, in this case, the SI = 250 cont
<t>In this example the path also consists of an SF of type 41 located at ains a choice between the
SFF1 and this is
followed by an SF of type 43, but in this case the SI = 250 contains a
choice between the
SFI located at SFF2 and the SFI located at SFF4.</t> SFI located at SFF2 and the SFI located at SFF4.</t>
<t>SFF1 will receive packets on the path from the classifier and will id
<t>SFF1 will receive packets on the path from the Classifier and will ide entify the path
ntify the path from the SPI (16). The initial SI will be 255, and so SFF1 will deliv
from the SPI (16). The initial SI will be 255 and so SFF1 will delive er the packets to the
r the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be decr
<t>When the packets are returned to SFF1 by the SFI the SI will be decre eased to 250 for
ased to 250 for the next hop. SFF1 now has a choice of next-hop SFFs to execute the
the next hop. SFF1 now has a choice of next hop SFF to execute the n next hop in the path.
ext hop in the path. It can either forward packets to SFF2 or SFF4 to execute a function o
It can either forward packets to SFF2 or SFF4 to execute a function o f Type 43. It uses
f type 43. It uses its local load-balancing algorithm to make this choice. The chosen S
its local load balancing algorithm to make this choice. The chosen S FF will send the
FF will send the
packets to the SFI that supports SFT 43 before forwarding the packets to their packets to the SFI that supports SFT 43 before forwarding the packets to their
destinations.</t> destinations.</t>
</section>
</section> <section anchor="exampleopen" numbered="true" toc="default">
<name>Example SFP with Open Choice of SFIs</name>
<section anchor="exampleopen" title="Example SFP With Open Choice of SFIs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP3: RD = 198.51.100.1/103, SPI = 17, SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0] [SI = 250, SFT = 44, RD = 0]
]]> ]]></sourcecode>
</artwork> <t>In this example, the path also consists of an SF of Type 41 located a
</figure> t SFF1, and this is
followed by an SI with an RD of zero and SF of Type 44. This means th
<t>In this example the path also consists of an SF of type 41 located at at a choice can be
SFF1 and this is made between any SFF that supports an SFI of Type 44.</t>
followed by an SI with an RD of zero and SF of type 44. This means th <t>SFF1 will receive packets on the path from the classifier and will id
at a choice can be entify the path
made between any SFF that supports an SFI of type 44.</t> from the SPI (17). The initial SI will be 255, and so SFF1 will deliv
er the packets to the
<t>SFF1 will receive packets on the path from the Classifier and will ide
ntify the path
from the SPI (17). The initial SI will be 255 and so SFF1 will delive
r the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be decr
<t>When the packets are returned to SFF1 by the SFI the SI will be decre eased to 250 for
ased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute
the next hop. SFF1 now has a free choice of next hop SFF to execute the next hop in the
the next hop in the path, selecting between all SFFs that support SFs of Type 44. Lookin
path selecting between all SFFs that support SFs of type 44. Looking g at the SFIRs it
at the SFIRs it has received, SFF1 knows that SF Type 44 is supported by SFF3 and SFF
has received, SFF1 knows that SF type 44 is supported by SFF3 and SFF 4. SFF1 uses its
4. SFF1 uses its local load-balancing algorithm to make this choice. The chosen SFF w
local load balancing algorithm to make this choice. The chosen SFF w ill send the packets
ill send the packets
to the SFI that supports SFT 44 before forwarding the packets to thei r destinations.</t> to the SFI that supports SFT 44 before forwarding the packets to thei r destinations.</t>
</section>
</section> <section anchor="examplesft" numbered="true" toc="default">
<name>Example SFP with Choice of SFTs</name>
<section anchor="examplesft" title="Example SFP With Choice of SFTs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP4: RD = 198.51.100.1/104, SPI = 18, SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2, [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ] SFT = 44, RD = 192.0.2.3/8 } ]
]]> ]]></sourcecode>
</artwork> <t>This example provides a choice of SF type in the second hop in the pa
</figure> th. The SI of 250
indicates a choice between SF Type 43 located at SF2 and SF Type 44 lo
<t>This example provides a choice of SF type in the second hop in the pat cated at SF3.</t>
h. The SI of 250 <t>SFF1 will receive packets on the path from the classifier and will id
indicates a choice between SF type 43 located at SF2 and SF type 44 lo entify the path
cated at SF3.</t> from the SPI (18). The initial SI will be 255, and so SFF1 will deliv
er the packets to the
<t>SFF1 will receive packets on the path from the Classifier and will ide
ntify the path
from the SPI (18). The initial SI will be 255 and so SFF1 will delive
r the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be decr
<t>When the packets are returned to SFF1 by the SFI the SI will be decrea eased to 250 for
sed to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execute
the next hop. SFF1 now has a free choice of next hop SFF to execute t the next hop in the
he next hop in the path, selecting between all SFFs that support an SF of Type 43 and
path selecting between all SFFs that support an SF of type 43 and SFF3 SFF3, which supports an
that supports an SF of Type 44. These may be completely different functions that are t
SF of type 44. These may be completely different functions that are t o be executed dependent
o be executed dependent on specific conditions, or they may be similar functions identified wi
on specific conditions, or may be similar functions identified with di th different type
fferent type identifiers (such as firewalls from different vendors). SFF1 uses
identifiers (such as firewalls from different vendors). SFF1 uses its its local policy and load-balancing algorithm to make this choice
local policy and load and may use additional information passed back from
balancing algorithm to make this choice, and may use additional inform
ation passed back from
the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI the local SFI to help inform its selection. The chosen SFF will send the packets to the SFI
that supports the chose SFT before forwarding the packets to their des that supports the chosen SFT before forwarding the packets to their de
tinations.</t> stinations.</t>
</section>
</section> <section anchor="exampleco" numbered="true" toc="default">
<name>Example Correlated Bidirectional SFPs</name>
<section anchor="exampleco" title="Example Correlated Bidirectional SFPs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP5: RD = 198.51.100.1/105, SPI = 19, SFP5: RD = 198.51.100.1/105, SPI = 19,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20, Assoc-Type = 1, Assoc-RD = 198.51.100.1/106, Assoc-SPI = 20,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP6: RD = 198.51.100.1/106, SPI = 20, SFP6: RD = 198.51.100.1/106, SPI = 20,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19, Assoc-Type = 1, Assoc-RD = 198.51.100.1/105, Assoc-SPI = 19,
[SI = 254, SFT = 43, RD = 192.0.2.2/2], [SI = 254, SFT = 43, RD = 192.0.2.2/2],
[SI = 249, SFT = 41, RD = 192.0.2.1/1] [SI = 249, SFT = 41, RD = 192.0.2.1/1]
]]> ]]></sourcecode>
</artwork> <t>This example demonstrates correlation of two SFPs to form a bidirecti
</figure> onal SFP, as
described in <xref target="correlation" format="default"/>.</t>
<t>This example demonstrates correlation of two SFPs to form a bidirectio <t>Two SFPRs are advertised by the controller. They have different SPIs
nal SFP as (19 and 20),
described in <xref target="correlation" />.</t>
<t>Two SFPRs are advertised by the Controller. They have different SPIs
(19 and 20)
so they are known to be separate SFPs, but they both have Association TLVs with Association Type so they are known to be separate SFPs, but they both have Association TLVs with Association Type
set to 1 indicating bidirectional SFPs. Each has an Associated SFPR-R set to 1, indicating bidirectional SFPs. Each has an "Associated SFPR
D field containing the value -RD" field containing the value
of the other SFPR-RD to correlated the two SFPs as a bidirectional pai of the other SFPR-RD to correlate the two SFPs as a bidirectional pair
r.</t> .</t>
<t>As can be seen from the SFPRs in this example, the paths are symmetri
<t>As can be seen from the SFPRs in this example, the paths are symmetric c: the hops in
: the hops in
SFP5 appear in the reverse order in SFP6.</t> SFP5 appear in the reverse order in SFP6.</t>
</section>
</section> <section anchor="exampleass" numbered="true" toc="default">
<name>Example Correlated Asymmetrical Bidirectional SFPs</name>
<section anchor="exampleass" title="Example Correlated Asymmetrical Bidirect <sourcecode><![CDATA[
ional SFPs" >
<figure>
<artwork>
<![CDATA[
SFP7: RD = 198.51.100.1/107, SPI = 21, SFP7: RD = 198.51.100.1/107, SPI = 21,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22, Assoc-Type = 1, Assoc-RD = 198.51.100.1/108, Assoc-SPI = 22,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
SFP8: RD = 198.51.100.1/108, SPI = 22, SFP8: RD = 198.51.100.1/108, SPI = 22,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21, Assoc-Type = 1, Assoc-RD = 198.51.100.1/107, Assoc-SPI = 21,
[SI = 254, SFT = 44, RD = 192.0.2.4/6], [SI = 254, SFT = 44, RD = 192.0.2.4/6],
[SI = 249, SFT = 41, RD = 192.0.2.1/1] [SI = 249, SFT = 41, RD = 192.0.2.1/1]
]]> ]]></sourcecode>
</artwork> <t>Asymmetric bidirectional SFPs can also be created. This example show
</figure> s a pair of SFPs
<t>Asymmetric bidirectional SFPs can also be created. This example shows
a pair of SFPs
with distinct SPIs (21 and 22) that are correlated in the same way as in the example in with distinct SPIs (21 and 22) that are correlated in the same way as in the example in
<xref target="exampleco" />.</t> <xref target="exampleco" format="default"/>.</t>
<t>However, unlike in that example, the SFPs are different in each direc
<t>However, unlike in that example, the SFPs are different in each direct tion. Both paths
ion. Both paths include a hop of SF Type 41, but SFP7 includes a hop of SF Type 43 sup
include a hop of SF type 41, but SFP7 includes a hop of SF type 43 sup ported at SFF2, while
ported at SFF2 while SFP8 includes a hop of SF Type 44 supported at SFF4.</t>
SFP8 includes a hop of SF type 44 supported at SFF4.</t> </section>
<section anchor="exampleloop" numbered="true" toc="default">
</section> <name>Example Looping in an SFP</name>
<sourcecode><![CDATA[
<section anchor="exampleloop" title="Example Looping in an SFP" >
<figure>
<artwork>
<![CDATA[
SFP9: RD = 198.51.100.1/109, SPI = 23, SFP9: RD = 198.51.100.1/109, SPI = 23,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 192.0.2.4/5], [SI = 250, SFT = 44, RD = 192.0.2.4/5],
[SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0}, [SI = 245, {SFT = 1, RD = {SPI=23, SI=255, Rsv=0},
SFT = 42, RD = 192.0.2.3/7 } ] SFT = 42, RD = 192.0.2.3/7 } ]
]]> ]]></sourcecode>
</artwork> <t>Looping and jumping are described in <xref target="looping" format="d
</figure> efault"/>. This example shows
<t>Looping and jumping are described in <xref target="looping" />. This
example shows
an SFP that contains an explicit loop-back instruction that is present ed as a choice an SFP that contains an explicit loop-back instruction that is present ed as a choice
within an SFP hop.</t> within an SFP hop.</t>
<t>The first two hops in the path (SI = 255 and SI = 250) are normal. T
<t>The first two hops in the path (SI = 255 and SI = 250) are normal. Th hat is, the packets
at is, the packets will be delivered to SFF1 and SFF4 in turn for execution of SFs of Typ
will be delivered to SFF1 and SFF4 in turn for execution of SFs of typ e 41 and 44,
e 41 and 44
respectively.</t> respectively.</t>
<t>The third hop (SI = 245) presents SFF4 with a choice of next hop. It
<t>The third hop (SI = 245) presents SFF4 with a choice of next hop. It can either forward
can either forward the packets to SFF3 for an SF of Type 42 (the second choice) or it can
the packets to SFF3 for an SF of type 42 (the second choice), or it ca loop back.</t>
n loop back.</t> <t>The loop-back entry in the SFPR for SI = 245 is indicated by the spec
ial-purpose SFT value
<t>The loop-back entry in the SFPR for SI = 245 is indicated by the speci
al purpose SFT value
1 ("Change Sequence"). Within this hop, the RD is interpreted as enco ding the SPI and SI 1 ("Change Sequence"). Within this hop, the RD is interpreted as enco ding the SPI and SI
of the next hop (see <xref target="changeseq" />. In this case the SP of the next hop (see <xref target="changeseq" format="default"/>).
I is 23 which In this case, the SPI is 23, which
indicates that this is loop or branch: i.e., the next hop is on the s indicates that this is a loop or branch, i.e., the next hop is on the
ame SFP. The SI is same SFP. The SI is
set to 255: this is a higher number than the current SI (245) indicati set to 255; this is a higher number than the current SI (245), indicat
ng a loop.</t> ing a loop.</t>
<t>SFF4 must make a choice between these two next hops. The packet
<t>SFF4 must make a choice between these two next hops. Either the packe will be either forwarded to SFF3 with the NSH SI decreased
ts will be forwarded to 245 or looped back to SFF1 with the NSH SI reset to 255.
to SFF3 with the NSH SI decreased to 245 or looped back to SFF1 with t
he NSH SI reset to 255.
This choice will be made according to local policy, information passed back by the local SFI, This choice will be made according to local policy, information passed back by the local SFI,
and details in the packets&apos; metadata that are used to prevent inf and details in the packets' metadata that are used to prevent infinite
inite looping.</t> looping.</t>
</section>
</section> <section anchor="examplebranch" numbered="true" toc="default">
<name>Example Branching in an SFP</name>
<section anchor="examplebranch" title="Example Branching in an SFP" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP10: RD = 198.51.100.1/110, SPI = 24, SFP10: RD = 198.51.100.1/110, SPI = 24,
[SI = 254, SFT = 42, RD = 192.0.2.3/7], [SI = 254, SFT = 42, RD = 192.0.2.3/7],
[SI = 249, SFT = 43, RD = 192.0.2.2/2] [SI = 249, SFT = 43, RD = 192.0.2.2/2]
SFP11: RD = 198.51.100.1/111, SPI = 25, SFP11: RD = 198.51.100.1/111, SPI = 25,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}] [SI = 250, SFT = 1, RD = {SPI=24, SI=254, Rsv=0}]
]]> ]]></sourcecode>
</artwork> <t>Branching follows a similar procedure to that for looping (and jumpin
</figure> g), as shown in
<xref target="exampleloop" format="default"/>. However, there are two
<t>Branching follows a similar procedure to that for looping (and jumping SFPs involved.</t>
) as shown in <t>SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for
<xref target="exampleloop" /> however there are two SFPs involved.</t> execution of
service functions of Type 42 and 43, respectively.</t>
<t>SFP10 shows a normal path with packets forwarded to SFF3 and SFF2 for <t>SFP11 starts as normal (SFF1 for an SF of Type 41), but then SFF1 pro
execution of cesses the
service functions of type 42 and 43 respectively.</t> next hop in the path and finds a "Change Sequence" special-purpose SFT
. The "SFIR-RD"
<t>SFP11 starts as normal (SFF1 for an SF of type 41), but then SFF1 proc field includes an SPI of 24, which indicates SFP10, not the current SF
esses the P. The SI in the
next hop in the path and finds a "Change Sequence" Special Purpose SFT
. The SFIR-RD
field includes an SPI of 24 which indicates SFP10, not the current SFP
. The SI in the
SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH t o 24/254 and SFIR-RD is 254, so SFF1 knows that it must set the SPI/SI in the NSH t o 24/254 and
send the packets to the appropriate SFF as advertised in the SFPR for SFP10 (that is, send the packets to the appropriate SFF, as advertised in the SFPR for SFP10 (that is,
SFF3).</t> SFF3).</t>
</section>
</section> <section anchor="examplestate" numbered="true" toc="default">
<name>Examples of SFPs with Stateful Service Functions</name>
<section anchor="examplestate" title="Examples of SFPs with Stateful Service <t>This section provides some examples to demonstrate establishing SFPs
Functions" > when there is a choice
<t>This section provides some examples to demonstrate establishing SFPs w
hen there is a choice
of service functions at a particular hop, and where consistency of cho ice is required in of service functions at a particular hop, and where consistency of cho ice is required in
both directions. The scenarios that give rise to this requirement are discussed in both directions. The scenarios that give rise to this requirement are discussed in
<xref target="stateful" />.</t> <xref target="stateful" format="default"/>.</t>
<section anchor="stateegsff" numbered="true" toc="default">
<section anchor="stateegsff" title="Forward and Reverse Choice Made at th <name>Forward and Reverse Choice Made at the SFF</name>
e SFF" > <t>Consider the topology shown in <xref target="egsfffig" format="defa
ult"/>. There are three SFFs
<t>Consider the topology shown in <xref target="egsfffig"/>. There ar
e three SFFs
arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of arranged neatly in a line, and the middle one (SFF2) supports three SFIs all of
SFT 42. These three instances can be used by SFF2 to load balance so that no SFT 42. These three instances can be used by SFF2 to load balance so that no
one instance is swamped.</t> one instance is swamped.</t>
<figure anchor="egsfffig">
<figure anchor="egsfffig" title="Example Where Choice is Made at the SFF" <name>Example Where Choice Is Made at the SFF</name>
> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
------ ------ ------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFIa | | SFIb | | SFIc | | SFI | | SFI | | SFIa | | SFIb | | SFIc | | SFI |
|SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43| |SFT=41| |SFT=42| |SFT=42| |SFT=42| |SFT=43|
------ ------\ ------ /------ ------ ------ ------\ ------ /------ ------
\ \ | / / \ \ | / /
--------- --------- --------- --------- --------- ---------
---------- | SFF1 | | SFF2 | | SFF3 | ---------- | SFF1 | | SFF2 | | SFF3 |
--> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|--> --> | |..|192.0.2.1|...|192.0.2.2|...|192.0.2.3|-->
--> |Classifier| --------- --------- --------- --> |Classifier| --------- --------- ---------
| | | |
---------- ----------
]]> ]]></artwork>
</artwork> </figure>
</figure>
<t>This leads to the following SFIRs being advertised.</t> <t>This leads to the following SFIRs being advertised.</t>
<figure> <sourcecode><![CDATA[
<artwork>
<![CDATA[
RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42 (for SFIa) RD = 192.0.2.2/11, SFT = 42 (for SFIa)
RD = 192.0.2.2/12, SFT = 42 (for SFIb) RD = 192.0.2.2/12, SFT = 42 (for SFIb)
RD = 192.0.2.2/13, SFT = 42 (for SFIc) RD = 192.0.2.2/13, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43 RD = 192.0.2.3/11, SFT = 43
]]> ]]></sourcecode>
</artwork> <t>The controller can create a single forward SFP (SFP12), giving SFF2
</figure> the choice
of which SFI to use to provide a function of SFT 42, as follows. T
<t>The controller can create a single forward SFP (SFP12) giving SFF2 he
the choice
of which SFI to use to provide function of SFT 42 as follows. The
load-balancing choice between the three available SFIs is assumed t o be load-balancing choice between the three available SFIs is assumed t o be
within the capabilities of the SFF and if the SFs are stateful it i s within the capabilities of the SFF, and if the SFs are stateful, it is
assumed that the SFF knows this and arranges load balancing in a st able, assumed that the SFF knows this and arranges load balancing in a st able,
flow-dependent way.</t> flow-dependent way.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP12: RD = 198.51.100.1/112, SPI = 26, SFP12: RD = 198.51.100.1/112, SPI = 26,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27, Assoc-Type = 1, Assoc-RD = 198.51.100.1/113, Assoc-SPI = 27,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11, [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12, 192.0.2.2/12,
192.0.2.2/13 }], 192.0.2.2/13 }],
[SI = 253, SFT = 43, RD = 192.0.2.3/11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
]]> ]]></sourcecode>
</artwork> <t>The reverse SFP (SFP13) in this case may also be created as shown b
</figure> elow, using
<t>The reverse SFP (SFP13) in this case may also be created as shown be
low using
association with the forward SFP and giving the load-balancing choic e to association with the forward SFP and giving the load-balancing choic e to
SFF2. This is safe, even in the case that the SFs of type 42 are st ateful SFF2. This is safe, even in the case that the SFs of Type 42 are st ateful,
because SFF2 is doing the load balancing in both directions and can apply because SFF2 is doing the load balancing in both directions and can apply
the same algorithm to ensure that packets associated with the same f low use the same algorithm to ensure that packets associated with the same f low use
the same SFI regardless of the direction of travel.</t> the same SFI regardless of the direction of travel.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP13: RD = 198.51.100.1/113, SPI = 27, SFP13: RD = 198.51.100.1/113, SPI = 27,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26, Assoc-Type = 1, Assoc-RD = 198.51.100.1/112, Assoc-SPI = 26,
[SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, {RD = 192.0.2.2/11, [SI = 254, SFT = 42, {RD = 192.0.2.2/11,
192.0.2.2/12, 192.0.2.2/12,
192.0.2.2/13 }], 192.0.2.2/13 }],
[SI = 253, SFT = 41, RD = 192.0.2.1/11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
]]> ]]></sourcecode>
</artwork> <t>How an SFF knows that an attached SFI is stateful is out of the sco
</figure> pe of this
<t>How an SFF knows that an attached SFI is stateful is out of scope of
this
document. It is assumed that this will form part of the process by which document. It is assumed that this will form part of the process by which
SFIs are registered as local to SFFs. <xref target="stateful" /> pr ovides SFIs are registered as local to SFFs. <xref target="stateful" forma t="default"/> provides
additional observations about the coordination of the use of statefu l SFIs additional observations about the coordination of the use of statefu l SFIs
in the case of bidirectional SFPs.</t> in the case of bidirectional SFPs.</t>
<t>In general, the problems of load balancing and the selection of the
<t>In general, the problems of load balancing and the selection of the same SFIs
same SFIs
in both directions of a bidirectional SFP can be addressed by using sufficiently in both directions of a bidirectional SFP can be addressed by using sufficiently
precisely specified SFPs (specifying the exact SFIs to use) and suit able precisely specified SFPs (specifying the exact SFIs to use) and suit able
programming of the Classifiers at each end of the SFPs to make sure that the programming of the classifiers at each end of the SFPs to make sure that the
matching pair of SFPs are used.</t> matching pair of SFPs are used.</t>
</section>
</section> <section anchor="stateeg1pll" numbered="true" toc="default">
<name>Parallel End-to-End SFPs with Shared SFF</name>
<section anchor="stateeg1pll" title="Parallel End-to-End SFPs with Shared <t>The mechanism described in <xref target="stateegsff" format="defaul
SFF" > t"/> might not be desirable because of
<t>The mechanism described in <xref target="stateegsff" /> might not be
desirable because of
the functional assumptions it places on SFF2 to be able to load bala nce with suitable flow the functional assumptions it places on SFF2 to be able to load bala nce with suitable flow
identification, stability, and equality in both directions. Instead , it may be desirable identification, stability, and equality in both directions. Instead , it may be desirable
to place the responsibility for flow classification in the Classifie r and let it determine to place the responsibility for flow classification in the classifie r and let it determine
load balancing with the implied choice of SFIs.</t> load balancing with the implied choice of SFIs.</t>
<t>Consider the network graph as shown in <xref target="egsfffig" form
<t>Consider the network graph as shown in <xref target="egsfffig" /> an at="default"/> and with the same set of
d with the same set of SFIRs as listed in <xref target="stateegsff" format="default"/>.
SFIRs as listed in <xref target="stateegsff" />. In this case the c In this case, the controller could specify
ontroller could specify
three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional three forward SFPs with their corresponding associated reverse SFPs. Each bidirectional
pair of SFPs uses a different SFI for the SF of type 42. The contro pair of SFPs uses a different SFI for the SF of Type 42. The contro
ller can instruct the ller can instruct the
Classifier how to place traffic on the three bidirectional SFPs, or classifier how to place traffic on the three bidirectional SFPs,
can treat them as a group or it can treat them as a group,
leaving the Classifier responsible for balancing the load.</t> leaving the classifier responsible for balancing the load.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP14: RD = 198.51.100.1/114, SPI = 28, SFP14: RD = 198.51.100.1/114, SPI = 28,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31, Assoc-Type = 1, Assoc-RD = 198.51.100.1/117, Assoc-SPI = 31,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11], [SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP15: RD = 198.51.100.1/115, SPI = 29, SFP15: RD = 198.51.100.1/115, SPI = 29,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32, Assoc-Type = 1, Assoc-RD = 198.51.100.1/118, Assoc-SPI = 32,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12], [SI = 254, SFT = 42, RD = 192.0.2.2/12],
skipping to change at line 2119 skipping to change at line 1804
Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29, Assoc-Type = 1, Assoc-RD = 198.51.100.1/115, Assoc-SPI = 29,
[SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/12], [SI = 254, SFT = 42, RD = 192.0.2.2/12],
[SI = 253, SFT = 41, RD = 192.0.2.1/11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP19: RD = 198.51.100.1/119, SPI = 33, SFP19: RD = 198.51.100.1/119, SPI = 33,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30, Assoc-Type = 1, Assoc-RD = 198.51.100.1/116, Assoc-SPI = 30,
[SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/13], [SI = 254, SFT = 42, RD = 192.0.2.2/13],
[SI = 253, SFT = 41, RD = 192.0.2.1/11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
]]> ]]></sourcecode>
</artwork> </section>
</figure> <section anchor="stateeg2pll" numbered="true" toc="default">
<name>Parallel End-to-End SFPs with Separate SFFs</name>
</section> <t>While the examples in Sections <xref target="stateegsff"
format="counter"/> and <xref target="stateeg1pll" format="counter"/>
<section anchor="stateeg2pll" title="Parallel End-to-End SFPs with Separa
te SFFs" >
<t>While the examples in <xref target="stateegsff" /> and <xref target=
"stateeg1pll" />
place the choice of SFI as subtended from the same SFF, it is also p ossible that the place the choice of SFI as subtended from the same SFF, it is also p ossible that the
SFIs are each subtended from a different SFF as shown in <xref targe SFIs are each subtended from a different SFF, as shown in <xref targ
t="eg2pllfig" />. et="eg2pllfig" format="default"/>.
In this case it is harder to coordinate the choices for forward and In this case, it is harder to coordinate the choices for forward and
reverse paths reverse paths
without some form of coordination between SFF1 and SFF3. Therefore without some form of coordination between SFF1 and SFF3. Therefore,
it would be it would be
normal to consider end-to-end parallel SFPs as described in <xref ta normal to consider end-to-end parallel SFPs, as described in <xref t
rget="stateeg1pll" />.</t> arget="stateeg1pll" format="default"/>.</t>
<figure anchor="eg2pllfig">
<figure anchor="eg2pllfig" title="Second Example With Parallel End-to-End <name>Second Example with Parallel End-to-End SFPs</name>
SFPs"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
------ ------
| SFIa | | SFIa |
|SFT=42| |SFT=42|
------ ------
------ | ------ |
| SFI | --------- | SFI | ---------
|SFT=41| | SFF5 | |SFT=41| | SFF5 |
------ ..|192.0.2.5|.. ------ ..|192.0.2.5|..
| ..: --------- :.. | ..: --------- :..
---------.: :.--------- ---------.: :.---------
skipping to change at line 2165 skipping to change at line 1846
: ------ : : ------ :
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=42| |SFT=42|
------ ------
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>In this case, five SFIRs are advertised as follows:</t>
<sourcecode><![CDATA[
<t>In this case, five SFIRs are advertised as follows:</t>
<figure>
<artwork>
<![CDATA[
RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.5/11, SFT = 42 (for SFIa) RD = 192.0.2.5/11, SFT = 42 (for SFIa)
RD = 192.0.2.6/11, SFT = 42 (for SFIb) RD = 192.0.2.6/11, SFT = 42 (for SFIb)
RD = 192.0.2.7/11, SFT = 42 (for SFIc) RD = 192.0.2.7/11, SFT = 42 (for SFIc)
RD = 192.0.2.3/11, SFT = 43 RD = 192.0.2.3/11, SFT = 43
]]> ]]></sourcecode>
</artwork> <t>In this case, the controller could specify three forward SFPs with
</figure> their corresponding
<t>In this case the controller could specify three forward SFPs with th
eir corresponding
associated reverse SFPs. Each bidirectional pair of SFPs uses a dif ferent SFF and SFI associated reverse SFPs. Each bidirectional pair of SFPs uses a dif ferent SFF and SFI
for middle hop (for an SF of type 42). The controller can instruct for the middle hop (for an SF of Type 42). The controller can instr
the Classifier how uct the classifier how
to place traffic on the three bidirectional SFPs, or can treat them to place traffic on the three bidirectional SFPs, or it can treat th
as a group leaving em as a group, leaving
the Classifier responsible for balancing the load.</t> the classifier responsible for balancing the load.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP20: RD = 198.51.100.1/120, SPI = 34, SFP20: RD = 198.51.100.1/120, SPI = 34,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37, Assoc-Type = 1, Assoc-RD = 198.51.100.1/123, Assoc-SPI = 37,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.5/11], [SI = 254, SFT = 42, RD = 192.0.2.5/11],
[SI = 253, SFT = 43, RD = 192.0.2.3/11] [SI = 253, SFT = 43, RD = 192.0.2.3/11]
SFP21: RD = 198.51.100.1/121, SPI = 35, SFP21: RD = 198.51.100.1/121, SPI = 35,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38, Assoc-Type = 1, Assoc-RD = 198.51.100.1/124, Assoc-SPI = 38,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11], [SI = 254, SFT = 42, RD = 192.0.2.6/11],
skipping to change at line 2227 skipping to change at line 1897
Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35, Assoc-Type = 1, Assoc-RD = 198.51.100.1/121, Assoc-SPI = 35,
[SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.6/11], [SI = 254, SFT = 42, RD = 192.0.2.6/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
SFP25: RD = 198.51.100.1/125, SPI = 39, SFP25: RD = 198.51.100.1/125, SPI = 39,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36, Assoc-Type = 1, Assoc-RD = 198.51.100.1/122, Assoc-SPI = 36,
[SI = 255, SFT = 43, RD = 192.0.2.3/11], [SI = 255, SFT = 43, RD = 192.0.2.3/11],
[SI = 254, SFT = 42, RD = 192.0.2.7/11], [SI = 254, SFT = 42, RD = 192.0.2.7/11],
[SI = 253, SFT = 41, RD = 192.0.2.1/11] [SI = 253, SFT = 41, RD = 192.0.2.1/11]
]]> ]]></sourcecode>
</artwork> </section>
</figure> <section anchor="stateegpllchc" numbered="true" toc="default">
<name>Parallel SFPs Downstream of the Choice</name>
</section> <t>The mechanism of parallel SFPs demonstrated in <xref
target="stateeg2pll" format="default"/>
<section anchor="stateegpllchc" title="Parallel SFPs Downstream of the Ch
oice" >
<t>The mechanism of parallel SFPs demonstrated in <xref target="stateeg
2pll" />
is perfectly functional and may be practical in many environments. However, is perfectly functional and may be practical in many environments. However,
there may be scaling concerns because of the large amount of state ( knowledge there may be scaling concerns because of the large amount of state ( knowledge
of SFPs, i.e., SFPR advertisements retained) if there is a very larg of SFPs -- i.e., SFPR advertisements retained) if there is a very la
e amount rge number
of choice of SFIs (for example, tens of instances of the same statef of possible SFIs (for example, tens of instances of the same statefu
ul SF), or l SF) or
if there are multiple choices of stateful SF along a path. This sit uation may if there are multiple choices of stateful SF along a path. This sit uation may
be mitigated using SFP fragments that are combined to form the end t be mitigated using SFP fragments that are combined to form the end-t
o end SFPs.</t> o-end SFPs.</t>
<t>The example presented here is necessarily simplistic but should con
<t>The example presented here is necessarily simplistic, but should con vey the
vey the basic principle. The example presented in <xref target="eg2pllchcfi
basic principle. The example presented in <xref target="eg2pllchcfi g" format="default"/> is
g" /> is similar to that in <xref target="stateeg2pll" format="default"/> but
similar to that in <xref target="stateeg2pll" /> but with an additio with an additional first
nal first
hop.</t> hop.</t>
<figure anchor="eg2pllchcfig">
<figure anchor="eg2pllchcfig" title="Example With Parallel SFPs Downstrea <name>Example with Parallel SFPs Downstream of Choice</name>
m of Choice"> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
<![CDATA[
------ ------
| SFIa | | SFIa |
|SFT=43| |SFT=43|
------ ------
------ ------ | ------ ------ |
| SFI | | SFI | --------- | SFI | | SFI | ---------
|SFT=41| |SFT=42| | SFF5 | |SFT=41| |SFT=42| | SFF5 |
------ ------ ..|192.0.2.5|.. ------ ------ ..|192.0.2.5|..
| | ..: --------- :.. | | ..: --------- :..
--------- ---------.: :.--------- --------- ---------.: :.---------
skipping to change at line 2279 skipping to change at line 1944
: ------ : : ------ :
:.---------.: :.---------.:
| SFF7 | | SFF7 |
|192.0.2.7| |192.0.2.7|
--------- ---------
| |
------ ------
| SFIc | | SFIc |
|SFT=43| |SFT=43|
------ ------
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The six SFIs are advertised as follows:</t>
<sourcecode><![CDATA[
<t>The six SFIs are advertised as follows:</t>
<figure>
<artwork>
<![CDATA[
RD = 192.0.2.1/11, SFT = 41 RD = 192.0.2.1/11, SFT = 41
RD = 192.0.2.2/11, SFT = 42 RD = 192.0.2.2/11, SFT = 42
RD = 192.0.2.5/11, SFT = 43 (for SFIa) RD = 192.0.2.5/11, SFT = 43 (for SFIa)
RD = 192.0.2.6/11, SFT = 43 (for SFIb) RD = 192.0.2.6/11, SFT = 43 (for SFIb)
RD = 192.0.2.7/11, SFT = 43 (for SFIc) RD = 192.0.2.7/11, SFT = 43 (for SFIc)
RD = 192.0.2.3/11, SFT = 44 RD = 192.0.2.3/11, SFT = 44
]]> ]]></sourcecode>
</artwork> <t>SFF2 is the point at which a load-balancing choice must be made. S
</figure> o "tail-end"
<t>SFF2 is the point at which a load balancing choice must be made. So
"tail-end"
SFPs are constructed as follows. Each takes in a different SFF that provides SFPs are constructed as follows. Each takes in a different SFF that provides
access to an SF of type 43.</t> access to an SF of Type 43.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP26: RD = 198.51.100.1/126, SPI = 40, SFP26: RD = 198.51.100.1/126, SPI = 40,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44, Assoc-Type = 1, Assoc-RD = 198.51.100.1/130, Assoc-SPI = 44,
[SI = 255, SFT = 43, RD = 192.0.2.5/11], [SI = 255, SFT = 43, RD = 192.0.2.5/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP27: RD = 198.51.100.1/127, SPI = 41, SFP27: RD = 198.51.100.1/127, SPI = 41,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45, Assoc-Type = 1, Assoc-RD = 198.51.100.1/131, Assoc-SPI = 45,
[SI = 255, SFT = 43, RD = 192.0.2.6/11], [SI = 255, SFT = 43, RD = 192.0.2.6/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
SFP28: RD = 198.51.100.1/128, SPI = 42, SFP28: RD = 198.51.100.1/128, SPI = 42,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46, Assoc-Type = 1, Assoc-RD = 198.51.100.1/132, Assoc-SPI = 46,
[SI = 255, SFT = 43, RD = 192.0.2.7/11], [SI = 255, SFT = 43, RD = 192.0.2.7/11],
[SI = 254, SFT = 44, RD = 192.0.2.3/11] [SI = 254, SFT = 44, RD = 192.0.2.3/11]
]]> ]]></sourcecode>
</artwork> <t>Now an end-to-end SFP with load-balancing choice can be constructed
</figure> as follows.
<t>Now an end-to-end SFP with load balancing choice can be constructed
as follows.
The choice made by SFF2 is expressed in terms of entering one of the three The choice made by SFF2 is expressed in terms of entering one of the three
"tail end" SFPs.</t> "tail-end" SFPs.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP29: RD = 198.51.100.1/129, SPI = 43, SFP29: RD = 198.51.100.1/129, SPI = 43,
[SI = 255, SFT = 41, RD = 192.0.2.1/11], [SI = 255, SFT = 41, RD = 192.0.2.1/11],
[SI = 254, SFT = 42, RD = 192.0.2.2/11], [SI = 254, SFT = 42, RD = 192.0.2.2/11],
[SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0}, [SI = 253, {SFT = 1, RD = {SPI=40, SI=255, Rsv=0},
RD = {SPI=41, SI=255, Rsv=0}, RD = {SPI=41, SI=255, Rsv=0},
RD = {SPI=42, SI=255, Rsv=0} } ] RD = {SPI=42, SI=255, Rsv=0} } ]
]]> ]]></sourcecode>
</artwork> <t>Now, despite the load-balancing choice being made elsewhere than at
</figure> the initial
classifier, it is possible for the reverse SFPs to be well construct
<t>Now, despite the load balancing choice being made other than at the ed without
initial
Classifier, it is possible for the reverse SFPs to be well-construct
ed without
any ambiguity. The three reverse paths appear as follows.</t> any ambiguity. The three reverse paths appear as follows.</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP30: RD = 198.51.100.1/130, SPI = 44, SFP30: RD = 198.51.100.1/130, SPI = 44,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40, Assoc-Type = 1, Assoc-RD = 198.51.100.1/126, Assoc-SPI = 40,
[SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.5/11], [SI = 254, SFT = 43, RD = 192.0.2.5/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP31: RD = 198.51.100.1/131, SPI = 45, SFP31: RD = 198.51.100.1/131, SPI = 45,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41, Assoc-Type = 1, Assoc-RD = 198.51.100.1/127, Assoc-SPI = 41,
[SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.6/11], [SI = 254, SFT = 43, RD = 192.0.2.6/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
SFP32: RD = 198.51.100.1/132, SPI = 46, SFP32: RD = 198.51.100.1/132, SPI = 46,
Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42, Assoc-Type = 1, Assoc-RD = 198.51.100.1/128, Assoc-SPI = 42,
[SI = 255, SFT = 44, RD = 192.0.2.4/11], [SI = 255, SFT = 44, RD = 192.0.2.4/11],
[SI = 254, SFT = 43, RD = 192.0.2.7/11], [SI = 254, SFT = 43, RD = 192.0.2.7/11],
[SI = 253, SFT = 42, RD = 192.0.2.2/11], [SI = 253, SFT = 42, RD = 192.0.2.2/11],
[SI = 252, SFT = 41, RD = 192.0.2.1/11] [SI = 252, SFT = 41, RD = 192.0.2.1/11]
]]> ]]></sourcecode>
</artwork> </section>
</figure> </section>
<section anchor="v6samples" numbered="true" toc="default">
</section> <name>Examples Using IPv6 Addressing</name>
</section> <t>This section provides several examples using IPv6 addressing. As
<section anchor="v6samples" title="Examples Using IPv6 Addressing">
<t>This section provides several examples using IPv6 addressing. As
will be seen from the examples, there is nothing special or clever will be seen from the examples, there is nothing special or clever
about using IPv6 addressing rather than IPv4 addressing.</t> about using IPv6 addressing rather than IPv4 addressing.</t>
<t>The reference network for these IPv6 examples is based on that descri
<t>The reference network for these IPv6 examples is based on that describ bed
ed at the top of <xref target="example" format="default"/> and shown in <
at the top of <xref target="example" /> and shown in <xref target="exa xref target="examplefig" format="default"/>.</t>
mplefig" />.</t> <t>Assume we have a service function overlay network with four SFFs (SFF
1, SFF3, SFF3, and SFF4).
<t>Assume we have a service function overlay network with four SFFs (SFF1
, SFF3, SFF3, and SFF4).
The SFFs have addresses in the underlay network as follows:</t> The SFFs have addresses in the underlay network as follows:</t>
<figure> <sourcecode><![CDATA[
<artwork>
<![CDATA[
SFF1 2001:db8::192:0:2:1 SFF1 2001:db8::192:0:2:1
SFF2 2001:db8::192:0:2:2 SFF2 2001:db8::192:0:2:2
SFF3 2001:db8::192:0:2:3 SFF3 2001:db8::192:0:2:3
SFF4 2001:db8::192:0:2:4 SFF4 2001:db8::192:0:2:4
]]> ]]></sourcecode>
</artwork> <t>Each SFF provides access to some SFIs from the four service function
</figure> types SFT=41, SFT=42,
SFT=43, and SFT=44, just as before:</t>
<t>Each SFF provides access to some SFIs from the four Service Function T <sourcecode><![CDATA[
ypes SFT=41, SFT=42,
SFT=43, and SFT=44 just as before:</t>
<figure>
<artwork>
<![CDATA[
SFF1 SFT=41 and SFT=42 SFF1 SFT=41 and SFT=42
SFF2 SFT=41 and SFT=43 SFF2 SFT=41 and SFT=43
SFF3 SFT=42 and SFT=44 SFF3 SFT=42 and SFT=44
SFF4 SFT=43 and SFT=44 SFF4 SFT=43 and SFT=44
]]> ]]></sourcecode>
</artwork> <t>The service function network also contains a controller with address
</figure> 2001:db8::198:51:100:1.</t>
<t>This example service function overlay network is shown in <xref targe
<t>The service function network also contains a Controller with address 2 t="eg6fig" format="default"/>.</t>
001:db8::198:51:100:1.</t> <figure anchor="eg6fig">
<name>Example Service Function Overlay Network</name>
<t>This example service function overlay network is shown in <xref target <artwork name="" type="" align="left" alt=""><![CDATA[
="eg6fig" />.</t>
<figure anchor="eg6fig" title="Example Service Function Overlay Networ
k">
<artwork>
<![CDATA[
------------------------ ------------------------
| Controller | | Controller |
| 2001:db8::198:51:100:1 | | 2001:db8::198:51:100:1 |
------------------------ ------------------------
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=41| |SFT=42| |SFT=41| |SFT=43| |SFT=41| |SFT=42| |SFT=41| |SFT=43|
------ ------ ------ ------ ------ ------ ------ ------
\ / \ / \ / \ /
------------------- ------------------- ------------------- -------------------
skipping to change at line 2443 skipping to change at line 2067
---------- ----------
------------------- ------------------- ------------------- -------------------
| SFF3 | | SFF4 | | SFF3 | | SFF4 |
|2001:db8::192:0:2:3| |2001:db8::192:0:2:4| |2001:db8::192:0:2:3| |2001:db8::192:0:2:4|
------------------- ------------------- ------------------- -------------------
/ \ / \ / \ / \
------ ------ ------ ------ ------ ------ ------ ------
| SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI | | SFI |
|SFT=42| |SFT=44| |SFT=43| |SFT=44| |SFT=42| |SFT=44| |SFT=43| |SFT=44|
------ ------ ------ ------ ------ ------ ------ ------
]]> ]]></artwork>
</artwork> </figure>
</figure> <t>The SFFs advertise routes to the SFIs they support. These advertisem
ents
<t>The SFFs advertise routes to the SFIs they support. These advertisements contain RDs that are set according to the network operator's
contain Route Distinguishers that are set according to the network operat
or&apos;s
configuration model. Note that in an IPv6 network, the RD is not large e nough to configuration model. Note that in an IPv6 network, the RD is not large e nough to
contain the full IPv6 address as only six octets are available so, in all contain the full IPv6 address, as only six octets are available. So, in a
of these IPv6 ll of these IPv6
examples, we use RDs of type 1 such that the available six octets are par examples, we use RDs of Type 1 such that the available six octets are par
titioned as four titioned as four
octets for an IPv4 address of the advertising SFF, and two octets that ar e a local index octets for an IPv4 address of the advertising SFF, and two octets that ar e a local index
of the SFI. Furthermore, we have chosen an IPv6 addressing scheme so tha t the low order of the SFI. Furthermore, we have chosen an IPv6 addressing scheme so tha t the low-order
four octets of the IPv6 address match an IPv4 address of the advertising node. This scheme four octets of the IPv6 address match an IPv4 address of the advertising node. This scheme
is chosen purely for convenience of documentation, and an operator is tot ally free to use is chosen purely for convenience of documentation, and an operator is tot ally free to use
any other scheme so long as it conforms to the definitions of SFIR and SF any other scheme so long as it conforms to the definitions of SFIR and
PR in SFPR in Sections
<xref target="sfiRoutes" /> and <xref target="sfpRoutes" />.</t> <xref target="sfiRoutes" format="counter"/> and <xref target="sfpRoutes"
format="counter"/>.</t>
<t>Observant readers will notice that this makes the BGP advertisements show <t>Observant readers will notice that this makes the BGP advertisements
n in these examples shown in these examples
exactly the same as in the previous examples. All that is different is t hat the advertising exactly the same as in the previous examples. All that is different is t hat the advertising
SFFs and Controller have IPv6 addresses.</t> SFFs and controller have IPv6 addresses.</t>
<t>Thus, we see the following SFIRs advertised.</t>
<t>Thus we see the following SFIRs advertised:</t> <t>The SFFs advertise routes to the SFIs they support. So we see the fo
llowing
<t>The SFFs advertise routes to the SFIs they support. So we see the fol
lowing
SFIRs:</t> SFIRs:</t>
<sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
RD = 192.0.2.1/1, SFT = 41 RD = 192.0.2.1/1, SFT = 41
RD = 192.0.2.1/2, SFT = 42 RD = 192.0.2.1/2, SFT = 42
RD = 192.0.2.2/1, SFT = 41 RD = 192.0.2.2/1, SFT = 41
RD = 192.0.2.2/2, SFT = 43 RD = 192.0.2.2/2, SFT = 43
RD = 192.0.2.3/7, SFT = 42 RD = 192.0.2.3/7, SFT = 42
RD = 192.0.2.3/8, SFT = 44 RD = 192.0.2.3/8, SFT = 44
RD = 192.0.2.4/5, SFT = 43 RD = 192.0.2.4/5, SFT = 43
RD = 192.0.2.4/6, SFT = 44 RD = 192.0.2.4/6, SFT = 44
]]> ]]></sourcecode>
</artwork> <t>Note that the addressing used for communicating between SFFs is taken
</figure> from the tunnel encapsulation attribute of the SFIR and not from the S
FIR-RD.</t>
<t>Note that the addressing used for communicating between SFFs is taken <section anchor="eg6explicit" numbered="true" toc="default">
from the Tunnel Encapsulation attribute of the SFIR and not from the S <name>Example Explicit SFP with No Choices</name>
FIR-RD.</t> <t>Consider the following SFPR similar to that in <xref target="exampl
eexplicit" format="default"/>.</t>
<section anchor="eg6explicit" title="Example Explicit SFP With No Choices <sourcecode><![CDATA[
" >
<t>Consider the following SFPR similar to that in <xref target="exampl
eexplicit" />.</t>
<figure>
<artwork>
<![CDATA[
SFP1: RD = 198.51.100.1/101, SPI = 15, SFP1: RD = 198.51.100.1/101, SPI = 15,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, RD = 192.0.2.2/2] [SI = 250, SFT = 43, RD = 192.0.2.2/2]
]]> ]]></sourcecode>
</artwork> <t>The SFP consists of an SF of Type 41 located at SFF1, followed by a
</figure> n SF
of Type 43 located at SFF2. This path is fully explicit, and each
<t>The Service Function Path consists of an SF of type 41 located at S SFF is
FF1 followed by an SF offered no choice in forwarding a packet along the path.</t>
of type 43 located at SFF2. This path is fully explicit and each S <t>SFF1 will receive packets on the path from the classifier and will
FF is identify the path
offered no choice in forwarding packet along the path.</t> from the SPI (15). The initial SI will be 255, and so SFF1 will de
liver the packets to the
<t>SFF1 will receive packets on the path from the Classifier and will
identify the path
from the SPI (15). The initial SI will be 255 and so SFF1 will del
iver the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be
<t>When the packets are returned to SFF1 by the SFI the SI will be de decreased to 250 for the next hop.
creased to 250 for the next hop. SFF1 has no flexibility in the choice of SFF to support the next-h
SFF1 has no flexibility in the choice of SFF to support the next h op SFI and will forward
op SFI and will forward the packet to SFF2, which will send the packets to the SFI that su
the packet to SFF2 which will send the packets to the SFI that sup pports SFT 43 before
ports SFT 43 before
forwarding the packets to their destinations.</t> forwarding the packets to their destinations.</t>
</section>
</section> <section anchor="eg6choice" numbered="true" toc="default">
<name>Example SFP with Choice of SFIs</name>
<section anchor="eg6choice" title="Example SFP With Choice of SFIs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP2: RD = 198.51.100.1/102, SPI = 16, SFP2: RD = 198.51.100.1/102, SPI = 16,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 43, {RD = 192.0.2.2/2, [SI = 250, SFT = 43, {RD = 192.0.2.2/2,
RD = 192.0.2.4/5 } ] RD = 192.0.2.4/5 } ]
]]> ]]></sourcecode>
</artwork> <t>In this example, like that in <xref target="examplechoice" format="
</figure> default"/>, the path also consists of an
SF of Type 41 located at SFF1, and this is followed by an SF of
<t>In this example, like that in <xref target="examplechoice" />, the Type 43; but in this case, the
path also consists of an
SF of type 41 located at SFF1 and this is followed by an SF of type
43, but in this case the
SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4.</t> SI = 250 contains a choice between the SFI located at SFF2 and the SFI located at SFF4.</t>
<t>SFF1 will receive packets on the path from the classifier and will
<t>SFF1 will receive packets on the path from the Classifier and will identify the path
identify the path from the SPI (16). The initial SI will be 255, and so SFF1 will de
from the SPI (16). The initial SI will be 255 and so SFF1 will del liver the packets to the
iver the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be de
<t>When the packets are returned to SFF1 by the SFI the SI will be de creased to 250 for
creased to 250 for the next hop. SFF1 now has a choice of next-hop SFFs to execute t
the next hop. SFF1 now has a choice of next hop SFF to execute th he next hop in the path.
e next hop in the path. It can either forward packets to SFF2 or SFF4 to execute a functio
It can either forward packets to SFF2 or SFF4 to execute a functio n of Type 43. It uses
n of type 43. It uses its local load-balancing algorithm to make this choice. The chose
its local load balancing algorithm to make this choice. The chose n SFF will send the
n SFF will send the
packets to the SFI that supports SFT 43 before forwarding the pack ets to their packets to the SFI that supports SFT 43 before forwarding the pack ets to their
destinations.</t> destinations.</t>
</section>
</section> <section anchor="eg6open" numbered="true" toc="default">
<name>Example SFP with Open Choice of SFIs</name>
<section anchor="eg6open" title="Example SFP With Open Choice of SFIs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP3: RD = 198.51.100.1/103, SPI = 17, SFP3: RD = 198.51.100.1/103, SPI = 17,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, SFT = 44, RD = 0] [SI = 250, SFT = 44, RD = 0]
]]> ]]></sourcecode>
</artwork> <t>In this example, like that in <xref target="exampleopen"
</figure> format="default"/>, the path also consists of an
SF of Type 41 located at SFF1, and this is followed by an SI with a
<t>In this example, like that in <xref target="exampleopen" /> the pat n RD of zero and SF of
h also consists of an Type 44. This means that a choice can be made between any SFF that
SF of type 41 located at SFF1 and this is followed by an SI with an supports an SFI of
RD of zero and SF of Type 44.</t>
type 44. This means that a choice can be made between any SFF that <t>SFF1 will receive packets on the path from the classifier and will
supports an SFI of identify the path
type 44.</t> from the SPI (17). The initial SI will be 255, and so SFF1 will de
liver the packets to the
<t>SFF1 will receive packets on the path from the Classifier and will
identify the path
from the SPI (17). The initial SI will be 255 and so SFF1 will del
iver the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be de
<t>When the packets are returned to SFF1 by the SFI the SI will be de creased to 250 for
creased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to exec
the next hop. SFF1 now has a free choice of next hop SFF to execu ute the next hop in the
te the next hop in the path, selecting between all SFFs that support SFs of Type 44. Loo
path selecting between all SFFs that support SFs of type 44. Look king at the SFIRs it
ing at the SFIRs it has received, SFF1 knows that SF Type 44 is supported by SFF3 and
has received, SFF1 knows that SF type 44 is supported by SFF3 and SFF4. SFF1 uses its
SFF4. SFF1 uses its local load-balancing algorithm to make this choice. The chosen SF
local load balancing algorithm to make this choice. The chosen SF F will send the packets
F will send the packets
to the SFI that supports SFT 44 before forwarding the packets to t heir destinations.</t> to the SFI that supports SFT 44 before forwarding the packets to t heir destinations.</t>
</section>
</section> <section anchor="eg6sft" numbered="true" toc="default">
<name>Example SFP with Choice of SFTs</name>
<section anchor="eg6sft" title="Example SFP With Choice of SFTs" > <sourcecode><![CDATA[
<figure>
<artwork>
<![CDATA[
SFP4: RD = 198.51.100.1/104, SPI = 18, SFP4: RD = 198.51.100.1/104, SPI = 18,
[SI = 255, SFT = 41, RD = 192.0.2.1/1], [SI = 255, SFT = 41, RD = 192.0.2.1/1],
[SI = 250, {SFT = 43, RD = 192.0.2.2/2, [SI = 250, {SFT = 43, RD = 192.0.2.2/2,
SFT = 44, RD = 192.0.2.3/8 } ] SFT = 44, RD = 192.0.2.3/8 } ]
]]> ]]></sourcecode>
</artwork> <t>This example, similar to that in <xref target="examplesft"
</figure> format="default"/>, provides a choice of SF type
in the second hop in the path. The SI of 250 indicates a choice be
<t>This example, similar to that in <xref target="examplesft" /> provi tween SF Type 43 located
des a choice of SF type through SF2 and SF Type 44 located at SF3.</t>
in the second hop in the path. The SI of 250 indicates a choice be <t>SFF1 will receive packets on the path from the classifier and will
tween SF type 43 located identify the path
through SF2 and SF type 44 located at SF3.</t> from the SPI (18). The initial SI will be 255, and so SFF1 will de
liver the packets to the
<t>SFF1 will receive packets on the path from the Classifier and will
identify the path
from the SPI (18). The initial SI will be 255 and so SFF1 will del
iver the packets to the
SFI for SFT 41.</t> SFI for SFT 41.</t>
<t>When the packets are returned to SFF1 by the SFI, the SI will be de
<t>When the packets are returned to SFF1 by the SFI the SI will be dec creased to 250 for
reased to 250 for the next hop. SFF1 now has a free choice of next-hop SFFs to execu
the next hop. SFF1 now has a free choice of next hop SFF to execut te the next hop in the
e the next hop in the path, selecting between all SFFs that support an SF of Type 43
path selecting between all SFFs that support an SF of type 43 and S and SFF3, which supports an
FF3 that supports an SF of Type 44. These may be completely different functions that ar
SF of type 44. These may be completely different functions that ar e to be executed dependent
e to be executed dependent on specific conditions, or they may be similar functions identified
on specific conditions, or may be similar functions identified with with different type
different type identifiers (such as firewalls from different vendors). SFF1
identifiers (such as firewalls from different vendors). SFF1 uses uses its local policy and load-balancing algorithm to make this
its local policy and load choice, and it may use additional information passed back from
balancing algorithm to make this choice, and may use additional inf
ormation passed back from
the local SFI to help inform its selection. The chosen SFF will se nd the packets to the SFI the local SFI to help inform its selection. The chosen SFF will se nd the packets to the SFI
that supports the chose SFT before forwarding the packets to their that supports the chosen SFT before forwarding the packets to their
destinations.</t> destinations.</t>
</section>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
</section> <name>Security Considerations</name>
<t>The mechanisms in this document use BGP for the control plane.
<section anchor="security" title="Security Considerations"> Hence, techniques such as those discussed in <xref target="RFC5925" forma
t="default"/>
<t>The mechanisms in this document use BGP for the control plane. can be used to help authenticate BGP sessions and, thus, the messages
Hence, techniques such as those discussed in <xref target="RFC5925" />]
can be used to help authenticate BGP sessions and thus the messages
between BGP peers, making it harder to spoof updates (which between BGP peers, making it harder to spoof updates (which
could be used to install bogus SFPs or to advertise false SIs) could be used to install bogus SFPs or advertise false SIs)
or withdrawals.</t> or withdrawals.</t>
<t>Further discussion of security considerations for BGP may be found in
the BGP specification itself <xref target="RFC4271" format="default"/> an
d the security
analysis for BGP <xref target="RFC4272" format="default"/>.
<t>Further discussion of security considerations for BGP may be found in <xref target="RFC5925" format="default"/> contains a discussion of the inappropr
the BGP specification itself <xref target="RFC4271" /> and in the securit iateness of the TCP
y MD5 signature option for protecting BGP sessions. <xref target="RFC6952"/> incl
analysis for BGP <xref target="RFC4272" />. The original discussion of t udes
he an analysis of BGP keying and authentication issues.</t>
use of the TCP MD5 signature option to protect BGP sessions is found in <t>Additionally, this document depends on other documents that specify BGP
<xref target="RFC5925" />, while <xref target="RFC6952" /> includes an
analysis of BGP keying and authentication issues.</t>
<t>Additionally, this document depends on other documents that specify BGP
Multiprotocol Extensions and the documents that define the attributes tha t Multiprotocol Extensions and the documents that define the attributes tha t
are carried by BGP UPDATEs of the SFC AFI/SAFI. <xref target="RFC4760" / > are carried by BGP UPDATEs of the SFC AFI/SAFI. <xref target="RFC4760" f ormat="default"/>
observes that the use of AFI/SAFI does not change the underlying security issues observes that the use of AFI/SAFI does not change the underlying security issues
inherent in the existing BGP. Relevant additional security measures are inherent in the existing BGP. Relevant additional security measures are
considered in <xref target="I-D.ietf-idr-tunnel-encaps" />.</t> considered in <xref target="RFC9012" format="default"/>.</t>
<t>This document does not fundamentally change the security behavior of BG
<t>This document does not fundamentally change the security behavior of BGP P
deployments, which depend considerably on the network operator&apos;s per deployments, which depend considerably on the network operator's percepti
ception on
of risk in their network. It may be observed that the application of the of risk in their network. It may be observed that the application of the
mechanisms described in this document are scoped to a single domain as im mechanisms described in this document is scoped to a single domain, as im
plied plied
by <xref target="RFC8300" /> noted in <xref target="funcover" /> of this by <xref target="RFC8300" format="default"/> and noted in <xref target="f
document. uncover" format="default"/> of this document.
Applicability of BGP within a single domain may enable a network operator to make Applicability of BGP within a single domain may enable a network operator to make
easier and more consistent decisions about what security measures to appl y, and the easier and more consistent decisions about what security measures to appl y, and the
domain boundary, which BGP enforces by definition, provides a safeguard t hat prevents domain boundary, which BGP enforces by definition, provides a safeguard t hat prevents
leakage of SFC programming in either direction at the boundary.</t> leakage of SFC programming in either direction at the boundary.</t>
<t>Service function chaining provides a significant attack opportunity; pa
<t>Service Function Chaining provides a significant attack opportunity: pack ckets can be diverted
ets can be diverted
from their normal paths through the network, packets can be made to execu te unexpected functions, and from their normal paths through the network, packets can be made to execu te unexpected functions, and
the functions that are instantiated in software can be subverted. Howeve r, this specification the functions that are instantiated in software can be subverted. Howeve r, this specification
does not change the existence of Service Function Chaining and security i does not change the existence of service function chaining, and security
ssues specific to issues specific to
Service Function Chaining are covered in <xref target="RFC7665" /> and service function chaining are covered in <xref target="RFC7665" format="d
<xref target="RFC8300" />.</t> efault"/> and
<xref target="RFC8300" format="default"/>.</t>
<t>This document defines a control plane for Service Function Chaining. Cle <t>This document defines a control plane for service function chaining. C
arly, this provides learly, this provides
an attack vector for a Service Function Chaining system as an attack on t an attack vector for a service function chaining system, as an attack on
his control plane this control plane
could be used to make the system misbehave. Thus, the security of the BG P system is critically could be used to make the system misbehave. Thus, the security of the BG P system is critically
important to the security of the whole Service Function Chaining system. The control plane important to the security of the whole service function chaining system. The control plane
mechanisms are very similar to those used for BGP/MPLS IP VPNs as describ ed in mechanisms are very similar to those used for BGP/MPLS IP VPNs as describ ed in
<xref target="RFC4364" />, and so the security considerations in that doc <xref target="RFC4364"/>, and so the security considerations in that docu
ument (Section 13) ment (Section <xref target="RFC4364" section="13" sectionFormat="bare"/>)
provide good guidance for securing SFC systems reliant on this specificat provide good guidance for securing service function chaining systems reli
ion. Of particular ant on this specification. Of particular
relevance is the need to securely distinguish between messages intended f or the control of relevance is the need to securely distinguish between messages intended f or the control of
different SFC overlays which is similar to the need to distinguish betwee different SFC overlays, which is similar to the need to distinguish betwe
n different VPNs. en different VPNs.
Section 19 of <xref target="RFC7432" /> also provides useful guidance on <xref target="RFC7432" section="19" sectionFormat="of"/> also provides us
the use of BGP in a eful guidance on the use of BGP in a
similar environment.</t> similar environment.</t>
<t>Note that a component of a service function chaining system that uses t
<t>Note that a component of an SFC system that uses the procedures described he procedures described in this document also
in this document also requires communications between a controller and the service function cha
requires communications between a Controller and the SFC network elements ining network elements (specifically the SFFs
(specifically the SFFs and classifiers). This communication covers instructing the classifiers
and Classifiers). This communication covers instructing the Classifiers using BGP mechanisms (see
using BGP mechanisms (see <xref target="fspecclassy" format="default"/>); therefore, the use of BGP
<xref target="fspecclassy" />), thus the use of BGP security is strongly security is strongly recommended. But it also
recommended. But it also covers other mechanisms for programming the classifier and instructing th
covers other mechanisms for programming the Classifier and instructing th e SFFs and SFs (for
e SFFs and SFs (for
example, to bind SFs to an SFF, and to cause the establishment of tunnels between SFFs). This example, to bind SFs to an SFF, and to cause the establishment of tunnels between SFFs). This
document does not cover these latter mechanisms and so their security is document does not cover these latter mechanisms, and so their security is
out of scope, but it out of scope, but it
should be noted that these communications provide an attack vector on the should be noted that these communications provide an attack vector on the
SFC system and so service function chaining system, and so
attention must be paid to ensuring that they are secure.</t> attention must be paid to ensuring that they are secure.</t>
<t>There is an intrinsic assumption in service function chaining systems t
<t>There is an intrinsic assumption in SFC systems that nodes that announce hat nodes that announce support for specific
support for specific SFs actually offer those functions and that SFs are not, themselves, atta
SFs actually offer those functions, and that SFs are not, themselves, att cked or subverted.
acked or subverted.
This is particularly important when the SFs are implemented as software t hat can be updated. This is particularly important when the SFs are implemented as software t hat can be updated.
Protection against this sort of concern forms part of the security of any SFC system and so is Protection against this sort of concern forms part of the security of any service function chaining system and so is
outside the scope of the control plane mechanisms described in this docum ent.</t> outside the scope of the control plane mechanisms described in this docum ent.</t>
<t>Similarly, there is a vulnerability if a rogue or subverted controller
<t>Similarly, there is a vulnerability if a rogue or subverted Controller an announces SFPs, especially
nounces SFPs especially if that controller "takes over" an existing SFP and changes its contents.
if that controller "takes over" an existing SFP and changes its contents. This corresponds
This is corresponds to a rogue BGP speaker entering a routing system, or even a Route Reflect
to a rogue BGP speaker entering a routing system, or even to a Route Refl or becoming
ector becoming
subverted. Protection mechanisms, as above, include securing BGP session s and protecting subverted. Protection mechanisms, as above, include securing BGP session s and protecting
software loads on the controllers.</t> software loads on the controllers.</t>
<t>In an environment where there is concern that rogue controllers might b
<t>In an environment where there is concern that rogue Controllers might be e introduced to the
introduced to the network and inject false SFPRs or take over and change existing SFPRs, it
network and inject false SFPRs or take over and change existing SFPRs, it is <bcp14>RECOMMENDED</bcp14> that
is RECOMMENDED that each SFF and classifier be configured with the identities of authorized c
each SFF and Classifier be configured with the identities of authorized C ontrollers. Thus, the
ontrollers. Thus, the
announcement of an SFPR by any other BGP peer would be rejected.</t> announcement of an SFPR by any other BGP peer would be rejected.</t>
<t>Lastly, note that <xref target="sfparules" format="default"/> makes two
<t>Lastly, note that <xref target="sfparules" /> makes two operational sugge operational suggestions that have
stions that have
implications for the stability and security of the mechanisms described i n this document: implications for the stability and security of the mechanisms described i n this document:
<list style="symbols"> </t>
<t>That modifications to active SFPs not be made.</t> <ul spacing="normal">
<t>That SPIs not be immediately re-used.</t> <li>That modifications to active SFPs not be made.</li>
</list></t> <li>That SPIs not be immediately reused.</li>
</ul>
</section>
<section anchor="iana" title="IANA Considerations">
<section anchor="afisafi" title="New BGP AF/SAFI">
<t>IANA maintains a registry of "Address Family Numbers". IANA is reques
ted to assign a new
Address Family Number from the "Standards Action" range called "BGP SF
C" (TBD1 in this
document) with this document as a reference.</t>
<t>IANA maintains a registry of "Subsequent Address Family Identifiers (S
AFI) Parameters". IANA
is requested to assign a new SAFI value from the "Standards Action" ra
nge called "BGP SFC"
(TBD2 in this document) with this document as a reference.</t>
</section>
<section anchor="ianasfpatt" title="New BGP Path Attribute">
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters
" with a subregistry of
"BGP Path Attributes". IANA is requested to assign a new Path attribu
te called "SFP attribute"
(TBD3 in this document) with this document as a reference.</t>
</section>
<section anchor="ianasftlv" title="New SFP Attribute TLVs Type Registry">
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters
". IANA is request to
create a new subregistry called the "SFP Attribute TLVs" registry.</t>
<t>Valid values are in the range 0 to 65535.
<list style="symbols">
<t>Values 0 and 65535 are to be marked "Reserved, not to be allocate
d".</t>
<t>Values 1 through 65534 are to be assigned according to the "First
Come
First Served" policy <xref target="RFC8126" />.</t>
</list></t>
<t>This document should be given as a reference for this registry.</t>
<t>The new registry should track:
<list style="symbols">
<t>Type</t>
<t>Name</t>
<t>Reference Document or Contact</t>
<t>Registration Date</t>
</list></t>
<t>The registry should initially be populated as follows:</t>
<figure>
<artwork>
<![CDATA[
Type | Name | Reference | Date
------+-------------------------+---------------+---------------
1 | Association TLV | [This.I-D] | Date-to-be-set
2 | Hop TLV | [This.I-D] | Date-to-be-set
3 | SFT TLV | [This.I-D] | Date-to-be-set
4 | MPLS Swapping/Stacking | [This.I-D] | Date-to-be-set
5 | SFP Traversal With MPLS | [This.I-D] | Date-to-be-set
]]>
</artwork>
</figure>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<section anchor="afisafi" numbered="true" toc="default">
<name>New BGP AF/SAFI</name>
<section anchor="ianaassoc" title="New SFP Association Type Registry"> <t>IANA maintains the "Address Family Numbers" registry. IANA has assig
ned a new
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters Address Family Number from the "Standards Action" range called "BGP SF
". IANA is request to C" (31), with this document as a reference.</t>
create a new subregistry called the "SFP Association Type" registry.</ <t>IANA maintains the "Subsequent Address Family Identifiers (SAFI) Para
t> meters" registry. IANA
has assigned a new SAFI value from the "Standards Action" range called
<t>Valid values are in the range 0 to 65535. "BGP SFC"
<list style="symbols"> (9), with this document as a reference.</t>
<t>Values 0 and 65535 are to be marked "Reserved, not to be allocate </section>
d".</t> <section anchor="ianasfpatt" numbered="true" toc="default">
<t>Values 1 through 65534 are to be assigned according to the "First <name>&quot;SFP attribute&quot; BGP Path Attribute</name>
Come <t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameter
First Served" policy <xref target="RFC8126" />.</t> s" with a subregistry of
</list></t> "BGP Path Attributes". IANA has assigned a new Path attribute called
"SFP attribute" with a value of 37 and with this document as a reference.</t>
<t>This document should be given as a reference for this registry.</t> </section>
<section anchor="ianasftlv" numbered="true" toc="default">
<t>The new registry should track: <name>&quot;SFP Attribute TLVs&quot; Registry</name>
<list style="symbols"> <t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameter
<t>Association Type</t> s". IANA has created a new subregistry called the "SFP Attribute TLVs" registry
<t>Name</t> .</t>
<t>Reference Document or Contact</t> <t>Valid values are in the range 0 to 65535.
<t>Registration Date</t> </t>
</list></t> <ul spacing="normal">
<t>The registry should initially be populated as follows:</t>
<figure> <li>Values 0 and 65535 are marked "Reserved".</li>
<artwork> <li>Values 1 through 65534 are to be assigned according to the "First
<![CDATA[ Come
Association Type | Name | Reference | Date First Served" policy <xref target="RFC8126" format="default"/>.</
-----------------+--------------------+------------+--------------- li>
1 | Bidirectional SFP | [This.I-D] | Date-to-be-set </ul>
]]> <t>This document is a reference for this registry.</t>
</artwork> <t>The registry tracks:
</figure> </t>
</section> <ul spacing="normal">
<li>Type</li>
<li>Name</li>
<li>Reference</li>
<li>Registration Date</li>
</ul>
<t>The registry is initially populated as follows:</t>
<table>
<name>SFP Attribute TLVs Subregistry Initial Contents</name>
<thead>
<tr>
<th>Type</th>
<th>Name</th>
<th>Reference</th>
<th>Registration Date</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>Association TLV</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>2</td>
<td>Hop TLV</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>3</td>
<td>SFT TLV</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>4</td>
<td>MPLS Swapping/Stacking</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>5</td>
<td>SFP Traversal With MPLS</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
</tbody>
</table>
</section>
<section anchor="ianaassoc" numbered="true" toc="default">
<name>&quot;SFP Association Type&quot; Registry</name>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameter
s". IANA has created a new subregistry called the "SFP Association Type" regist
ry.</t>
<t>Valid values are in the range 0 to 65535.
</t>
<ul spacing="normal">
<li>Values 0 and 65535 are marked "Reserved".</li>
<li>Values 1 through 65534 are assigned according to the "First Come
First Served" policy <xref target="RFC8126" format="default"/>.</
li>
</ul>
<t>This document is given as a reference for this registry.</t>
<t>The new registry tracks:
</t>
<ul spacing="normal">
<li>Association Type</li>
<li>Name</li>
<li>Reference</li>
<li>Registration Date</li>
</ul>
<t>The registry should initially be populated as follows:</t>
<section anchor="SFTreg" title="New Service Function Type Registry"> <table>
<name>SFP Association Type Subregistry Initial Contents</name>
<thead>
<tr>
<th>Association Type</th>
<th>Name</th>
<th>Reference</th>
<th>Date</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>Bidirectional SFP</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
</tbody>
</table>
<t>IANA is request to create a new top-level registry called "Service Fun ction Chaining Service Function Types".</t> </section>
<t>Valid values are in the range 0 to 65535. <section anchor="SFTreg" numbered="true" toc="default">
<list style="symbols"> <name>&quot;Service Function Chaining Service Function Types&quot; Regis
<t>Values 0 and 65535 are to be marked "Reserved, not to be allocate try</name>
d".</t> <t>IANA has created a new top-level registry called "Service Function Ch
<t>Values 1 through 31 are to be assigned by "Standards Action" <xre aining Service Function Types".</t>
f target="RFC8126" /> and are referred to <t>Valid values are in the range 0 to 65535.
as the Special Purpose SFT values.</t> </t>
<t>Values 32 through 64495 are to be assigned according to the "Firs <ul spacing="normal">
t Come <li>Values 0 and 65535 are marked "Reserved".</li>
First Served" policy <xref target="RFC8126" />.</t> <li>Values 1 through 31 are to be assigned by "Standards Action" <xref
<t>Values 64496 through 65534 are for Private Use and are not to be target="RFC8126" format="default"/> and are referred to
recorded by IANA.</t> as the "special-purpose SFT values".</li>
</list></t> <li>Values 32 through 64495 are to be assigned according to the "First
Come
First Served" policy <xref target="RFC8126" format="default"/>.</
li>
<li>Values 64496 through 65534 are for Private Use and are not to be r
ecorded by IANA.</li>
</ul>
<t>This document is given as a reference for this registry.</t>
<t>The registry tracks:
</t>
<ul spacing="normal">
<li>Value</li>
<li>Name</li>
<li>Reference</li>
<li>Registration Date</li>
</ul>
<t>This document should be given as a reference for this registry.</t> <t>The registry is initially populated as follows.</t>
<t>The new registry should track: <table>
<list style="symbols"> <name>Service Function Chaining Service Function Types Registry Initial
<t>Value</t> Contents</name>
<t>Name</t> <thead>
<t>Reference Document or Contact</t> <tr>
<t>Registration Date</t> <th>Value</th>
</list></t> <th>Name</th>
<th>Reference</th>
<th>Date</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>1</td>
<td>Change Sequence</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>2-31</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
<tr>
<td>32</td>
<td>Classifier</td>
<td>RFC 9015, <xref
target="I-D.dawra-idr-bgp-ls-sr-service-segments" format="default
"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>33</td>
<td>Firewall</td>
<td>RFC 9015, <xref
target="I-D.dawra-idr-bgp-ls-sr-service-segments" format="default
"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<t>The registry should initially be populated as follows where [I-D.darwa <td>34</td>
] should <td>Load balancer</td>
be expanded to <xref target="I-D.dawra-idr-bgp-ls-sr-service-segments" <td>RFC 9015, <xref
/>.</t> target="I-D.dawra-idr-bgp-ls-sr-service-segments" format="default
"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<figure> <td>35</td>
<artwork> <td>Deep packet inspection engine</td>
<![CDATA[ <td>RFC 9015, <xref
Value | Name | Reference | Date target="I-D.dawra-idr-bgp-ls-sr-service-segments" format="default
------+-------------------------+------------+--------------- "/></td>
0 | Reserved, not to be | [This.I-D] | Date-to-be-set <td>2020-09-02</td>
| allocated | | </tr>
1 | Change Sequence | [This.I-D] | Date-to-be-set <tr>
2-31 | Unassigned | |
32 | Classifier | [This.I-D] | Date-to-be-set
| | [I-D.dawra]|
33 | Firewall | [This.I-D] | Date-to-be-set
| | [I-D.dawra]|
34 | Load balancer | [This.I-D] | Date-to-be-set
| | [I-D.dawra]|
35 | Deep packet inspection | [This.I-D] | Date-to-be-set
| engine | [I-D.dawra]|
36 | Penalty box | [This.I-D] | Date-to-be-set
| | [RFC8300] |
37 | WAN accelerator | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC8300] |
38 | Application accelerator | [This.I-D] | Date-to-be-set
| | [RFC7665] |
39 | TCP optimizer | [This.I-D] | Date-to-be-set
| | [RFC7665] |
40 | Network Address | [This.I-D] | Date-to-be-set
| Translator | [RFC7665] |
41 | NAT44 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC3022] |
42 | NAT64 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC6146] |
43 | NPTv6 | [This.I-D] | Date-to-be-set
| | [RFC7665] |
| | [RFC6296] |
44 | Lawful intercept | [This.I-D] | Date-to-be-set
| | [RFC7665] |
45 | HOST_ID injection | [This.I-D] | Date-to-be-set
| | [RFC7665] |
46 | HTTP header enrichment | [This.I-D] | Date-to-be-set
| | [RFC7665] |
47 | Caching engine | [This.I-D] | Date-to-be-set
| | [RFC7665] |
48- | | |
-65534|Unassigned | |
65535 | Reserved, not to be | |
| allocated | [This.I-D] | Date-to-be-set
]]>
</artwork>
</figure>
</section> <td>36</td>
<td>Penalty box</td>
<td>RFC 9015, <xref target="RFC8300"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>37</td>
<td>WAN accelerator</td>
<td>RFC 9015, <xref target="RFC7665"/>, <xref target="RFC8300"/><
/td>
<td>2020-09-02</td>
</tr>
<tr>
<td>38</td>
<td>Application accelerator</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>39</td>
<td>TCP optimizer</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>40</td>
<td>Network Address Translator</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>41</td>
<td>NAT44</td>
<td>RFC 9015, <xref target="RFC7665"/>, <xref target="RFC3022"/>
</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>42</td>
<td>NAT64</td>
<td>RFC 9015, <xref target="RFC7665"/>, <xref target="RFC614
6"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>43</td>
<td>NPTv6</td>
<td>RFC 9015, <xref target="RFC7665"/>, <xref target="RFC6296"/><
/td>
<td>2020-09-02</td>
<section anchor="ExpExtComreg" title="New Generic Transitive Experimental Us </tr>
e Extended Community Sub-Types"> <tr>
<td>44</td>
<td>Lawful intercept</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>45</td>
<td>HOST_ID injection</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>46</td>
<td>HTTP header enrichment</td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td>
</tr>
<tr>
<td>47</td>
<td>Caching engine </td>
<td>RFC 9015, <xref target="RFC7665"/></td>
<td>2020-09-02</td></tr>
<tr>
<td>48-64495</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
<tr>
<td>64496-65534</td>
<td>Reserved for Private Use</td>
<td></td>
<td></td>
</tr>
<tr>
<td>65535</td>
<td>Reserved, not to be allocated </td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
</tbody>
</table>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters </section>
" with a subregistry of <section anchor="ExpExtComreg" numbered="true" toc="default">
"Generic Transitive Experimental Use Extended Community Sub-Type". IA <name>Flow Specification for SFC Classifiers</name>
NA is requested to assign a <t>IANA maintains a registry of "Border Gateway Protocol (BGP) Extended
new sub-type as follows: Communities" with a subregistry of
<list style="symbls"> "Generic Transitive Experimental Use Extended Community Sub-Types". I
<t>"Flow Specification for SFC Classifiers" (TBD4 in this document) ANA has assigned a
with this document as the reference.</t> new subtype as follows:
</list></t> </t>
<ul empty="true" spacing="normal">
<li>"Flow Specification for SFC Classifiers" with a value of 0x0d and
with this document as the reference.</li>
</ul>
</section>
<section anchor="TransExtComreg" numbered="true" toc="default">
<name>New BGP Transitive Extended Community Type</name>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Extended
Communities" with a subregistry of
"BGP Transitive Extended Community Types". IANA has assigned a new ty
pe as follows:
</t>
<ul empty="true" spacing="normal">
<li>SFC (Sub-Types are defined in the "SFC Extended Community
Sub-Types" registry) with a value of 0x0b and with this document as
the reference.</li>
</ul>
</section>
<section anchor="SFCExtComreg" numbered="true" toc="default">
<name>&quot;SFC Extended Community Sub-Types&quot; Registry</name>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameter
s". IANA has created a new subregistry called the "SFC Extended Community Sub-T
ypes" registry.</t>
<t>IANA has included the following note:
</t>
<aside><t>
This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first
octet (the "Type" field) is set to 0x0b.</t>
</aside>
<t>The allocation policy for this registry is First Come First Served.</
t>
<t>Valid values are 0 to 255. The value 0 is reserved and should not be
allocated.</t>
<t>IANA has populated this registry with the following entries:</t>
<table>
<name>SFC Extended Community Sub-Types Subregistry Initial Contents</na
me>
<thead>
<tr>
<th>Sub-Type
Value</th>
<th>Name</th>
<th>Reference</th>
<th>Date</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9015</td>
<td></td>
</tr>
<tr>
<td>1</td>
<td>SFIR pool identifier</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</tr>
<tr>
<td>2</td>
<td>MPLS Label Stack Mixed Swapping/Stacking Labels</td>
<td>RFC 9015</td>
<td>2020-09-02</td>
</section> </tr>
<tr>
<td>3-255</td>
<td>Unassigned</td>
<td></td>
<td></td>
</tr>
</tbody>
</table>
<section anchor="TransExtComreg" title="New BGP Transitive Extended Communit </section>
y Type"> <section anchor="SpiSiRep" numbered="true" toc="default">
<name>New SPI/SI Representation Sub-TLV</name>
<t>IANA has assigned a codepoint from the "BGP Tunnel Encapsulation Attr
ibute
Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV" with a val
ue of 16 and with this
document as the reference.</t>
</section>
<section anchor="IANAbits" numbered="true" toc="default">
<name>&quot;SFC SPI/SI Representation Flags&quot; Registry</name>
<t>IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" regi
stry and has created an associated registry called the "SFC SPI/SI Representatio
n Flags" registry.</t>
<t>Bits are to be assigned by Standards Action. The field is 16 bits lon
g, and bits are counted
from the most significant bit as bit zero.</t>
<t>IANA has populated the registry as follows:</t>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters <table>
" with a subregistry of <name>SFC SPI/SI Representation Flags Registry Initial Contents</name>
"BGP Transitive Extended Community Types". IANA is requested to assig <thead>
n a new type as follows: <tr>
<list style="symbols"> <th>Value</th>
<t>SFC (Sub-Types are defined in the "SFC Extended Community Sub-Ty <th>Name</th>
pes" registry) (TBD6 in this document) with this document as the reference.</t> <th>Reference</th>
</list></t> </tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>NSH data plane</td>
<td>RFC 9015</td>
</tr>
<tr>
<td>1</td>
<td>MPLS data plane</td>
<td>RFC 9015</td>
</tr>
</tbody>
</table>
</section>
</section> </section>
<section anchor="SFCExtComreg" title="New SFC Extended Community Sub-Types R </middle>
egistry"> <back>
<t>IANA maintains a registry of "Border Gateway Protocol (BGP) Parameters
". IANA is requested to
create a new sub-registry called the "SFC Extended Community Sub-Types
Registry".</t>
<t>IANA should include the following note replacing the string "TBD6" wit
h the value assigned
for <xref target="TransExtComreg" />:
<list style="none">
<t>This registry contains values of the second octet (the "Sub-Type"
field) of an extended community when the value of the first
octet (the "Type" field) is set to TBD6.</t>
</list></t>
<t>The allocation policy for this registry should be First Come First Ser ved.</t> <displayreference target="I-D.dawra-idr-bgp-ls-sr-service-segments" to="BGP-LS-S R"/>
<t>Valid values are 0 to 255. The value 0 is reserved and should not be <references>
allocated.</t> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4360.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<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.7432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7606.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7665.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8300.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8595.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8596.xml"/>
<t>IANA is requested to populate this registry with the following entries :</t> <!--[I-D.ietf-idr-rfc5575bis]; Pub'd as RFC 8955-->
<figure> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<artwork> FC.8955.xml"/>
<![CDATA[
Sub-Type | | |
Value | Name | Reference | Date
---------+----------------------+-------------+---------------
0 | Reserved, not to be | |
| allocated | |
1 | SFIR Pool Identifier | [This.I-D] | Date-to-be-set
2 | MPLS Label Stack | [This.I-D] | Date-to-be-set
| Mixed Swapping/ | |
| Stacking Labels | |
3-255 | Unassigned | |
]]>
</artwork>
</figure>
<t>All other values should be marked "Unassigned".</t> <!--[I-D.ietf-idr-tunnel-encaps]; Pub'd as RFC 9012-->
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9012.xml"/>
</section> </references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3022.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6146.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6296.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.7498.xml"/>
<section anchor="SpiSiRep" title="SPI/SI Representation"> <!-- [I-D.dawra-idr-bgp-ls-sr-service-segments] IESG state I-D Exists -->
<t>IANA is requested to assign a codepoint from the "BGP Tunnel Encapsula <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.dawra-i
tion Attribute dr-bgp-ls-sr-service-segments.xml"/>
Sub-TLVs" registry for the "SPI/SI Representation Sub-TLV" (TBD5 in th
is document) with this
document being the reference.</t>
</references>
</references>
<section anchor="acks" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Thanks to <contact fullname="Tony Przygienda"/>, <contact
fullname="Jeff Haas"/>, and <contact fullname="Andy Malis"/> for helpful
comments, and to
<contact fullname="Joel Halpern"/> for discussions that improved this
document. <contact fullname="Yuanlong Jiang"/> provided
a useful review and caught some important issues. <contact fullname="Ste
phane Litkowski"/> did an
exceptionally good and detailed Document Shepherd review.</t>
<t><contact fullname="Andy Malis"/> contributed text that formed the
basis of <xref target="mpls-encaps" format="default"/>.</t>
<t><contact fullname="Brian Carpenter"/> and <contact fullname="Martin
Vigoureux"/> provided useful reviews during IETF Last Call.
Thanks also to <contact fullname="Sheng Jiang"/>, <contact
fullname="Med Boucadair"/>, <contact fullname="Ravi Singh"/>, <contact
fullname="Benjamin Kaduk"/>, <contact fullname="Roman Danyliw"/>,
<contact fullname="Adam Roach"/>, <contact fullname="Alvaro Retana"/>, <c
ontact fullname="Barry Leiba"/>, and <contact fullname="Murray Kucherawy"/> for
review comments.
<contact fullname="Ketan Talaulikar"/> provided helpful discussion of
the SFT codepoint registry. <contact fullname="Ron Bonica"/>
kept us honest on the difference between an RD and an RT; <contact
fullname="Benjamin Kaduk"/> kept us on message
about the difference between an RD and an Extended Community.</t>
</section> </section>
<section anchor="IANAbits" title="SFC SPI/SI Representation Flags Registry"> <section anchor="contributors" numbered="false" toc="default">
<name>Contributors</name>
<t>IANA maintains the "BGP Tunnel Encapsulation Attribute Sub-TLVs" regist <contact fullname="Stuart Mackie">
ry and is requested to <organization>Juniper Networks</organization>
create an associated registry called the "SFC SPI/SI Representation Fla <address>
gs" registry.</t> <email>wsmackie@juinper.net</email>
<t>Bits are to be assigned by Standards Action. The field is 16 bits long, </address>
and bits are counted </contact>
from the the most significant bit as bit zero.</t>
<t>IANA is requested to populate the registry as follows:</t> <contact fullname="Keyur Patel">
<organization>Arrcus, Inc.</organization>
<address>
<email>keyur@arrcus.com</email>
</address>
</contact>
<figure> <contact fullname="Avinash Lingala">
<artwork> <organization>AT&amp;T</organization>
<![CDATA[ <address>
Bit number | Name | Reference <email>ar977m@att.com</email>
-----------+----------------------+----------- </address>
TBD9 | NSH data plane | [This.I-D] </contact>
TBD10 | MPLS data plane | [This.I-D]
]]>
</artwork>
</figure>
</section> </section>
</section> </back>
<section anchor="contributors" title="Contributors">
<figure>
<artwork>
<![CDATA[
Stuart Mackie
Juniper Networks
Email: wsmackie@juinper.net
Keyur Patel
Arrcus, Inc.
Email: keyur@arrcus.com
Avinash Lingala
AT&T
Email: ar977m@att.com
]]>
</artwork>
</figure>
</section>
<section anchor="acks" title="Acknowledgements">
<t>Thanks to Tony Przygienda, Jeff Haas, and Andy Malis for helpful comments
, and to
Joel Halpern for discussions that improved this document. Yuanlong Jiang
provided
a useful review and caught some important issues. Stephane Litkowski did
an
exceptionally good and detailed document shepherd review.</t>
<t>Andy Malis contributed text that formed the basis of <xref target="mpls-e
ncaps" />.</t>
<t>Brian Carpenter and Martin Vigoureux provided useful reviews during IETF
last call.
Thanks also to Sheng Jiang, Med Boucadair, Ravi Singh, Benjamin Kaduk, Ro
man Danyliw,
Adam Roach, Alvaro Retana, Barry Leiba, and Murray Kucherawy for review c
omments.
Ketan Talaulikar provided helpful discussion of the SFT code point regist
ry. Ron Bonica
kept us honest on the difference between an RD and RT; Benjamin Kaduk kep
t us on message
about the differnce between an RD and an extended community.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC4271;
&RFC4360;
&RFC4364;
&RFC4760;
&RFC7432;
&RFC7606;
&RFC7665;
&RFC8126;
&RFC8174;
&RFC8300;
&RFC8595;
&RFC8596;
<?rfc include="reference.I-D.ietf-idr-rfc5575bis"?>
<?rfc include="reference.I-D.ietf-idr-tunnel-encaps"?>
</references>
<references title="Informative References">
&RFC3022;
&RFC4272;
&RFC5925;
&RFC6146;
&RFC6296;
&RFC6952;
&RFC7498;
<?rfc include="reference.I-D.dawra-idr-bgp-ls-sr-service-segments"?>
</references>
</back>
</rfc> </rfc>
 End of changes. 372 change blocks. 
2934 lines changed or deleted 2605 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/