rfc8986xml2.original.xml   rfc8986.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY NET_PGM_ILL PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-
ids/reference.I-D.filsfils-spring-srv6-net-pgm-illustration.xml">
<!ENTITY TILFA PUBLIC "" "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/re
ference.I-D.ietf-rtgwg-segment-routing-ti-lfa.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8200 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8200.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4364.xml">
<!ENTITY RFC6437 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6437.xml">
<!ENTITY RFC2473 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2473.xml">
<!ENTITY RFC7432 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7432.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8402.xml">
<!ENTITY RFC8214 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8214.xml">
<!ENTITY RFC8754 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8754.xml">
<!ENTITY RFC4664 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4664.xml">
<!ENTITY RFC4762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4762.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC4761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4761.xml">
<!ENTITY RFC8317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8317.xml">
<!ENTITY RFC4193 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4193.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-spring-srv6-
<?rfc strict="yes" ?> network-programming-28"
<?rfc toc="yes"?> number="8986" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" ca
<?rfc tocompact="yes"?> tegory="std"
<?rfc tocdepth="3"?> consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sor
<?rfc tocindent="yes"?> tRefs="true"
<?rfc symrefs="yes"?> <!-- use symbolic references tags, i.e, [RFC2119] instead version="3">
of [1] -->
<?rfc sortrefs="yes"?> <!-- sort the reference entries alphabetically -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?> <!-- control vertical white space -->
<?rfc subcompact="no"?> <!-- keep one blank line between list items -->
<?rfc autobreaks="yes"?>
<rfc category="std" docName="draft-ietf-spring-srv6-network-programming-28" ipr=
"trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
,
or pre5378Trust200902 -->
<front> <front>
<title abbrev="SRv6 Network Programming">Segment Routing over IPv6 (SRv6) N
etwork Programming</title>
<seriesInfo name="RFC" value="8986"/>
<!--title abbrev="Abbreviated Title">SRv6 Network Programming</title> --> <author fullname="Clarence Filsfils" initials="C." surname="Filsfils" role="
<title>SRv6 Network Programming</title> editor">
<organization>Cisco Systems, Inc.</organization>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils" role= <address>
"editor"> <postal>
<organization>Cisco Systems, Inc.</organization> <street/>
<address> <city/>
<postal> <region/>
<street></street> <code/>
<city></city> <country>Belgium</country>
<region></region> </postal>
<code></code> <phone/>
<country>Belgium</country> <email>cf@cisco.com</email>
</postal> </address>
<phone></phone> </author>
<email>cf@cisco.com</email> <author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo"
</address> role="editor">
</author> <organization>Cisco Systems, Inc.</organization>
<address>
<author fullname="Pablo Camarillo Garvia" initials="P." surname="Camarillo" <postal>
role="editor" > <street/>
<organization>Cisco Systems, Inc.</organization> <city/>
<address> <region/>
<postal> <code/>
<street></street> <country>Spain</country>
<city></city> </postal>
<region></region> <email>pcamaril@cisco.com</email>
<code></code> </address>
<country>Spain</country> </author>
</postal> <author fullname="John Leddy" initials="J." surname="Leddy">
<email>pcamaril@cisco.com</email> <organization>Akamai Technologies</organization>
</address> <address>
</author> <postal>
<street/>
<author fullname="John Leddy" initials="J." surname="Leddy"> <city/>
<organization>Individual Contributor</organization> <region/>
<address> <code/>
<postal> <country>United States of America</country>
<street></street> </postal>
<city></city> <email>john@leddy.net</email>
<region></region> </address>
<code></code> </author>
<country>United States of America</country> <author fullname="Daniel Voyer" initials="D." surname="Voyer">
</postal> <organization>Bell Canada</organization>
<email>john@leddy.net</email> <address>
</address> <postal>
</author> <street/>
<city/>
<author fullname="Daniel Voyer" initials="D." surname="Voyer"> <region/>
<organization>Bell Canada</organization> <code/>
<address> <country>Canada</country>
<postal> </postal>
<street></street> <email>daniel.voyer@bell.ca</email>
<city></city> </address>
<region></region> </author>
<code></code> <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<country>Canada</country> <organization abbrev="SoftBank">SoftBank</organization>
</postal> <address>
<email>daniel.voyer@bell.ca</email> <postal>
</address>
</author>
<author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
<organization abbrev="SoftBank">SoftBank</organization>
<address>
<postal>
<street>1-9-1,Higashi-Shimbashi,Minato-Ku</street>
<city>Tokyo 105-7322</city>
<region></region>
<code></code>
<country>Japan</country>
</postal>
<phone></phone>
<email>satoru.matsushima@g.softbank.co.jp</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone></phone>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<date />
<area>General</area>
<workgroup>SPRING</workgroup>
<keyword>SRv6</keyword>
<keyword>Segment Routing</keyword>
<keyword>IPv6 Segment Routing</keyword>
<!-- Keywords will be incorporated into HTML output <country>Japan</country>
files in a meta tag but they have no effect on text or nroff </postal>
output. If you submit your draft to the RFC Editor, the <phone/>
keywords will be used for the search engine. --> <email>satoru.matsushima@g.softbank.co.jp</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country>China</country>
</postal>
<phone/>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<date year="2021" month="February" />
<area>General</area>
<workgroup>SPRING</workgroup>
<keyword>SRv6</keyword>
<keyword>Segment Routing</keyword>
<keyword>IPv6 Segment Routing</keyword>
<abstract> <abstract>
<t>The SRv6 Network Programming framework enables a network operator <t>The Segment Routing over IPv6 (SRv6) Network Programming framework enab
or an application to specify a packet processing program by encoding a sequence les a
of instructions in the IPv6 packet header.</t> network operator or an application to specify a packet processing
<t>Each instruction is implemented on one or several nodes in the ne program by encoding a sequence of instructions in the IPv6 packet
twork and identified by an SRv6 Segment Identifier in the packet.</t> header.</t>
<t>This document defines the SRv6 Network Programming concept and sp <t>Each instruction is implemented on one or several nodes in the
ecifies the base set of SRv6 behaviors that enables the creation of interoperabl network and identified by an SRv6 Segment Identifier in the packet.</t>
e overlays with underlay optimization.</t> <t>This document defines the SRv6 Network Programming concept and
</abstract> specifies the base set of SRv6 behaviors that enables the creation of
</front> interoperable overlays with underlay optimization.</t>
</abstract>
<middle> </front>
<section title="Introduction"> <middle>
<t>Segment Routing <xref target="RFC8402" /> leverages the source ro <section numbered="true" toc="default">
uting paradigm. An ingress node steers a packet through an ordered list of instr <name>Introduction</name>
uctions, called segments. Each one of these instructions represents a function t
o be called at a specific location in the network. A function is locally defined
on the node where it is executed and may range from simply moving forward in th
e Segment List to any complex user-defined behavior. Network programming combine
s segment routing functions, both simple and complex, to achieve a networking ob
jective that goes beyond mere packet routing.</t>
<t>This document defines the SRv6 Network Programming concept and sp
ecifies the main segment routing behaviors to enable the creation of interoperab
le overlays with underlay optimization.</t>
<t>The companion document <xref target="I-D.filsfils-spring-srv6-net
-pgm-illustration" /> illustrates the concepts defined in this document.</t>
<t>Familiarity with the <xref target="RFC8754">Segment Routing Heade
r</xref> is expected.</t>
</section>
<section title="Terminology">
<t>The following terms used within this document are defined in <xre
f target="RFC8402" />: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
SID, SR Policy, Prefix-SID, and Adj-SID.</t>
<t>The following terms used within this document are defined in <xre
f target="RFC8754" />: SRH, SR Source Node, Transit Node, SR Segment Endpoint No
de, Reduced SRH, Segments Left and Last Entry.</t>
<t>SL: The Segments Left field of the SRH</t>
<t>FIB: Forwarding Information Base. A FIB lookup is a lookup in th
e forwarding table.</t>
<t>SA: Source Address</t>
<t>DA: Destination Address</t>
<t>SRv6 SID function: The function part of the SID is an opaque iden
tification of a local behavior bound to the SID. It is formally defined in <xref
target="sid_format" /> of this document.</t>
<t>SRv6 Segment Endpoint behavior: A packet processing behavior exec
uted at an SRv6 Segment Endpoint Node. <xref target="behaviors" /> of this docum
ent defines SRv6 Segment Endpoint behaviors related to traffic-engineering and o
verlay use-cases. Other behaviors (e.g. service programming) are outside the sco
pe of this document.</t>
<t>An SR Policy is resolved to a SID list. A SID list is represented <t>Segment Routing <xref target="RFC8402" format="default"/> leverages
as &lt;S1, S2, S3&gt; where S1 is the first SID to visit, S2 is the second SID the source routing paradigm. An ingress node steers a packet through an
to visit and S3 is the last SID to visit along the SR path.</t> ordered list of instructions, called "segments". Each one of these
instructions represents a function to be called at a specific location
in the network. A function is locally defined on the node where it is
executed and may range from simply moving forward in the segment list to
any complex user-defined behavior. Network Programming combines Segment
Routing functions, both simple and complex, to achieve a networking
objective that goes beyond mere packet routing.</t>
<t>This document defines the SRv6 Network Programming concept and
specifies the main Segment Routing behaviors to enable the creation of
interoperable overlays with underlay optimization.</t>
<t><xref
target="I-D.filsfils-spring-srv6-net-pgm-illustration"
format="default"/> illustrates the concepts defined in this
document.</t>
<t>Familiarity with the <xref target="RFC8754" format="default">Segment
Routing Header</xref> is expected.</t>
</section>
<section numbered="true" toc="default">
<name>Terminology</name>
<t>The following terms used within this document are defined in <xref
target="RFC8402" format="default"/>: Segment Routing (SR), SR Domain, Segm
ent
ID (SID), SRv6, SRv6 SID, SR Policy, Prefix-SID, and Adj-SID.</t>
<t>The following terms used within this document are defined in <xref
target="RFC8754" format="default"/>: Segment Routing Header (SRH), SR
source node, transit node, SR Segment Endpoint Node, Reduced SRH,
Segments Left, and Last Entry.</t>
<t>(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:<list sty <t>The following terms are used in this document as defined below:</t>
le="format - ">
<t>Source Address is SA, Destination Address is DA, and next-hea
der is SRH.</t>
<t>SRH with SID list &lt;S1, S2, S3&gt; with Segments Left = SL.
</t>
<t>Note the difference between the &lt;&gt; and () symbols: &lt;
S1, S2, S3&gt; represents a SID list where S1 is the first SID and S3 is the las
t SID to traverse. (S3, S2, S1; SL) represents the same SID list but encoded in
the SRH format where the rightmost SID in the SRH is the first SID and the leftm
ost SID in the SRH is the last SID. When referring to an SR policy in a high-lev
el use-case, it is simpler to use the &lt;S1, S2, S3&gt; notation. When referrin
g to an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notat
ion is more convenient.</t>
<t>The payload of the packet is omitted.</t>
</list></t>
<t>Per-VRF VPN label: a single label for the entire VRF that is shar ed by all routes from that VRF (<xref target="RFC4364"/> Section 4.3.2)</t> <dl>
<t>Per-CE VPN label: a single label for each attachment circuit that <dt>FIB:
is shared by all routes with the same "outgoing attachment circuit" (<xref targ </dt>
et="RFC4364"/> Section 4.3.2)</t> <dd>Forwarding Information Base. A FIB lookup is a lookup in the forwarding tabl
e.
</dd>
<section title="Requirements Language"> <dt>SA:
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL </dt>
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPT <dd>Source Address
IONAL" in this document are to be interpreted as described in BCP 14 <xref targe </dd>
t="RFC2119" /> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>
</section>
</section>
<section title="SRv6 SID"> <dt>DA:
<t>RFC8402 defines an SRv6 Segment Identifier as an IPv6 address exp </dt>
licitly associated with the segment.</t> <dd>Destination Address
</dd>
<t>When an SRv6 SID is in the Destination Address field of an IPv6 h <dt>L3:
eader of a packet, it is routed through Transit Nodes in an IPv6 network as an I </dt>
Pv6 address.</t> <dd>Layer 3
</dd>
<t>Its processing is defined in <xref target="RFC8754" /> section 4. <dt>L2:
3 and reproduced here as a reminder. <list style="empty"> </dt>
<dd>Layer 2
</dd>
<t>Without constraining the details of an implementation, the SR <dt>MAC:
segment endpoint node creates Forwarding Information Base (FIB) entries for its </dt>
local SIDs.</t> <dd>Media Access Control
</dd>
<t>When an SRv6-capable node receives an IPv6 packet, it perform <dt>EVPN:
s a longest-prefix-match lookup on the packet's destination address. This looku </dt>
p can return any of the following: <list style="format * "> <dd>Ethernet VPN
</dd>
<t>A FIB entry that represents a locally instantiated SRv6 S <dt>ESI:
ID</t> </dt>
<t>A FIB entry that represents a local interface, not locall <dd>Ethernet Segment Identifier
y instantiated as an SRv6 SID</t> </dd>
<t>A FIB entry that represents a nonlocal route</t>
<t>No Match</t>
</list></t>
</list></t>
<t><xref target="behaviors" /> of this document defines a new set of <dt>Per-CE VPN label:
SRv6 SID behaviors in addition to that defined in <xref target="RFC8754" /> Sec </dt>
tion 4.3.1.</t> <dd>A single label for each attachment circuit that is shared by all routes
with the same "outgoing attachment circuit" (<xref target="RFC4364"
format="default" sectionFormat="of" section="4.3.2"/>)
</dd>
<section title="SID Format" anchor="sid_format"> <dt>Per-VRF VPN label:
<t>This document defines an SRv6 SID as consisting of LOC:FUNCT: </dt>
ARG, where a locator (LOC) is encoded in the L most significant bits of the SID,
followed by F bits of function (FUNCT) and A bits of arguments (ARG). L, the l
ocator length, is flexible, and an operator is free to use the locator length of
their choice. F and A may be any value as long as L+F+A &lt;= 128. When L+F+A i
s less than 128 then the remaining bits of the SID MUST be zero.</t>
<t>A locator may be represented as B:N where B is the SRv6 SID b <dd>A single label for the entire VPN Routing and Forwarding (VRF) table that is
lock (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the identifi shared by all routes from that VRF (<xref target="RFC4364" format="default"
er of the parent node instantiating the SID.</t> sectionFormat="of" section="4.3.2"/>)
</dd>
<t>When the LOC part of the SRv6 SIDs is routable, it leads to t <dt>SL:
he node which instantiates the SID.</t> </dt>
<dd>The Segments Left field of the SRH
</dd>
<t>The FUNCT is an opaque identification of a local behavior bou <dt>SRv6 SID function:
nd to the SID.</t> </dt>
<dd>The function part of the SID is an opaque identification of a local
behavior bound to the SID. It is formally defined in <xref target="sid_format"
format="default"/> of this document.
</dd>
<t>The term &quot;function&quot; refers to the bit-string in the <dt>SRv6 Endpoint behavior:
SRv6 SID. The term &quot;behavior&quot; identifies the behavior bound to the SI </dt>
D. Some behaviors are defined in Section 4 of this document.</t> <dd><t>A packet processing behavior executed at an SRv6 Segment Endpoint
Node. <xref target="behaviors" format="default"/> of this document defines
SRv6 Endpoint behaviors related to traffic-engineering and overlay
use cases. Other behaviors (e.g., service programming) are outside the scope of
this document.
</t>
<t>An SRv6 Segment Endpoint Behavior may require additional info rmation for its processing (e.g. related to the flow or service). This informati on may be encoded in the ARG bits of the SID.</t> </dd>
<t>In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 endpoint behavior specification.</t> </dl>
<t>The ARG value of a routed SID SHOULD remain constant among pa <t>An SR Policy is resolved to a SID list. A SID list is represented as
ckets in a given flow. Varying ARG values among packets in a flow may result in &lt;S1, S2, S3&gt; where S1 is the first SID to visit, S2 is the second SID to
different ECMP hashing and cause re-ordering.</t> visit, and S3 is the last SID to visit along the SR path.</t>
</section> <t>(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:</t>
<section title="SID Allocation within an SR domain"> <ul spacing="normal"><li>Source Address (SA), Destination Address (DA),
<t>Locators are assigned consistent with IPv6 infrastructure all and next header (SRH).</li> <li><t>SRH with SID list &lt;S1, S2, S3&gt;
ocation. For example, a network operator may: with Segments Left = SL.</t>
<list style="symbols">
<t>Assign block B::/48 to the SR domain</t>
<t>Assign a unique B:N::/64 block to each SRv6-enabled n
ode in the domain</t>
</list>
</t>
<t>As an example, one mobile service provider has commercially d
eployed SRv6 across more than 1000 commercial routers and 1800 whitebox routers.
All these devices are enabled for SRv6 and advertise SRv6 SIDs. The provider hi
storically deployed IPv6 and assigned infrastructure addresses from ULA space <x
ref target="RFC4193" />. They specifically allocated three /48 prefixes (Country
X, Country Y, Country Z) to support their SRv6 infrastructure. From those /48 p
refixes each router was assigned a /64 prefix from which all SIDs of that router
are allocated.</t>
<t>In another example, a large mobile and fixed-line service pro <t>Note the difference between the
vider has commercially deployed SRv6 in their country-wide network. This provide &lt;&gt; and () symbols: &lt;S1, S2, S3&gt; represents a SID list where
r is assigned a /20 prefix by an RIR (Regional Internet Registry). They sub-allo S1 is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL)
cated a few /48 prefixes to their infrastructure to deploy SRv6. Each router is represents the same SID list but encoded in the SRH format where the
assigned a /64 prefix from which all SIDs of that router are allocated.</t> rightmost SID in the SRH is the first SID and the leftmost SID in the
SRH is the last SID. When referring to an SR Policy in a high-level
use case, it is simpler to use the &lt;S1, S2, S3&gt; notation. When
referring to an illustration of the detailed packet behavior, the (S3,
S2, S1; SL) notation is more convenient.</t></li>
<t>IPv6 address consumption in both these examples is minimal, r <li>The payload of the packet is omitted.</li>
epresenting less than one billionth and one millionth of the available address s </ul>
pace, respectively.</t>
<t>A service provider receiving the current minimum allocation o <section numbered="true" toc="default">
f a /32 from an RIR may assign a /48 prefix to their infrastructure deploying SR <name>Requirements Language</name>
v6, and subsequently allocate /64 prefixes for SIDs at each SRv6 node. The /48 a
ssignment is one sixty-five thousandth (1/2^16) of the usable IPv6 address space
available for assignment by the provider.</t>
<t>When an operator instantiates a SID at a node, they specify a <t>
SID value B:N:FUNCT and the behavior bound to the SID using one of the SRv6 End The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
point Behavior codepoint of the registry defined in this document (see <xref tar "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
get="endpoint_cp_types" />).</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<t>The node advertises the SID, B:N:FUNCT, in the control-plane </section>
(see <xref target="cp" />) together with the SRv6 Endpoint Behavior codepoint id </section>
entifying the behavior of the SID.</t> <section numbered="true" toc="default">
<name>SRv6 SID</name>
<t><xref target="RFC8402"/> defines an SRv6 Segment Identifier as an IPv6
address
explicitly associated with the segment.</t>
<t>When an SRv6 SID is in the Destination Address field of an IPv6
header of a packet, it is routed through transit nodes in an IPv6
network as an IPv6 address.</t>
<t>Its processing is defined in <xref target="RFC8754"
format="default" sectionFormat="of" section="4.3"/> and reproduced here as
a reminder: </t>
<t>An SR Source Node cannot infer the behavior by examination of <blockquote>
the FUNCT value of a SID.</t> <t>Without constraining the details of an implementation, the SR
segment endpoint node creates Forwarding Information Base (FIB)
entries for its local SIDs.</t>
<t>Therefore, the SRv6 Endpoint Behavior codepoint is advertised <t>When an SRv6-capable node receives an IPv6 packet, it performs a
along with the SID in the control plane.</t> longest-prefix-match lookup on the packet's destination address.
This lookup can return any of the following: </t>
<t>An SR Source Node uses the SRv6 Endpoint Behavior codepoint t <ul spacing="normal"><li>A FIB entry that represents a locally instant
o map the received SID (B:N:FUNCT) to a behavior.</t> iated SRv6 SID</li>
<li>A FIB entry that represents a local interface, not locally insta
ntiated as an SRv6 SID</li>
<li>A FIB entry that represents a nonlocal route</li>
<li>No Match</li>
</ul></blockquote>
<t>An SR Source Node selects a desired behavior at an advertisin <t><xref target="behaviors" format="default"/> of this document defines
g node by selecting the SID (B:N:FUNCT) advertised with the desired behavior.</t a new set of SRv6 SID behaviors in addition to that defined in <xref
> target="RFC8754" format="default" sectionFormat="of" section="4.3.1"/>.</t
>
<section anchor="sid_format" numbered="true" toc="default">
<name>SID Format</name>
<t>As an example, a network operator may: <t>This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
<list style="symbols"> where a locator (LOC) is encoded in the L most significant bits of the
<t>Assign an SRv6 SID block 2001:db8:bbbb::/48 from thei SID, followed by F bits of function (FUNCT) and A bits of arguments
r in-house operation block for their SRv6 infrastructure</t> (ARG). L, the locator length, is flexible, and an operator is free to
<t>Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to one pa use the locator length of their choice. F and A may be any value as
rticular router, for example Router 3, in their SR Domain</t> long as L+F+A &lt;= 128. When L+F+A is less than 128, then the
<t>At Router 3, within the locator 2001:db8:bbbb:3::/64, remaining bits of the SID <bcp14>MUST</bcp14> be zero.</t>
the network operator or the router performs dynamic assignment for: <t>A locator may be represented as B:N where B is the SRv6 SID block
<list> (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is the
<t>Function 0x0100 associated with the behavior identifier of the parent node instantiating the SID.</t>
End.X (Endpoint with cross-connect) between router 3 and its connected neighbor <t>When the LOC part of the SRv6 SIDs is routable, it leads to the
router, for example Router 4. This function is encoded as 16-bit value and has n node, which instantiates the SID.</t>
o arguments (F=16, A=0).<vspace /> <t>The FUNCT is an opaque identification of a local behavior bound to th
This SID is advertised in the control plane as 2 e SID.</t>
001:db8:bbbb:3:100:: with SRv6 Endpoint Behavior codepoint value of 5.</t> <t>The term "function" refers to the bit string in the SRv6 SID. The
<t>Function 0x0101 associated with the behavior term "behavior" identifies the behavior bound to the SID. Some
End.X (Endpoint with cross-connect) between router 3 and its connected neighbor behaviors are defined in <xref target="behaviors"/> of this
router, for example Router 2. This function is encoded as 16-bit value and has n document.</t>
o arguments (F=16, A=0).<vspace /> <t>An SRv6 Endpoint behavior may require additional
This SID is advertised in the control plane as 2 information for its processing (e.g., related to the flow or
001:db8:bbbb:3:101:: with SRv6 Endpoint Behavior codepoint value of 5.</t> service). This information may be encoded in the ARG bits of the
</list> SID.</t>
</t>
</list>
</t>
<t>These examples do not preclude any other IPv6 addressing allo
cation scheme.</t>
</section>
<section title="SID Reachability"> <t>In such a case, the semantics and format of the ARG bits are
<t>Most often, the node N would advertise IPv6 prefix(es) matchi defined as part of the SRv6 Endpoint behavior specification.</t>
ng the LOC parts covering its SIDs or shorter-mask prefix. The distribution of t <t>The ARG value of a routed SID <bcp14>SHOULD</bcp14> remain constant a
hese advertisements and calculation of their reachability are specific to the ro mong packets in a given flow. Varying ARG values among packets in a flow may re
uting protocol and are outside of the scope of this document.</t> sult in different ECMP hashing and cause reordering.</t>
</section>
<t>An SRv6 SID is said to be routed if its SID belongs to an IPv <section numbered="true" toc="default">
6 prefix advertised via a routing protocol. An SRv6 SID that does not fulfill th <name>SID Allocation within an SR Domain</name>
is condition is non-routed.</t> <t>Locators are assigned consistent with IPv6 infrastructure allocation.
For example, a network operator may:
</t>
<ul spacing="normal">
<li>Assign block B::/48 to the SR domain</li>
<li>Assign a unique B:N::/64 block to each SRv6-enabled node in the do
main</li>
</ul>
<t>Let's provide a classic illustration:</t> <t>As an example, one mobile service provider has commercially
deployed SRv6 across more than 1000 commercial routers and 1800
whitebox routers. All these devices are enabled for SRv6 and advertise
SRv6 SIDs. The provider historically deployed IPv6 and assigned
infrastructure addresses from the Unique Local Address (ULA) space <xref
target="RFC4193" format="default"/>. They specifically allocated three
/48 prefixes (Country X, Country Y, Country Z) to support their SRv6
infrastructure. From those /48 prefixes, each router was assigned a /64
prefix from which all SIDs of that router are allocated.</t>
<t>In another example, a large mobile and fixed-line service provider
has commercially deployed SRv6 in their country-wide network. This
provider is assigned a /20 prefix by a Regional Internet
Registry (RIR). They sub-allocated a few /48 prefixes to their
infrastructure to deploy SRv6. Each router is assigned a /64 prefix
from which all SIDs of that router are allocated.</t>
<t>IPv6 address consumption in both these examples is minimal,
representing less than one billionth and one millionth of the
available address space, respectively.</t>
<t>Node N is configured explicitly with two SIDs: 2001:db8:b:1:1 <t>A service provider receiving the current minimum allocation of a
00:: and 2001:db8:b:2:101::.</t> /32 prefix from an RIR may assign a /48 prefix to their infrastructure
deploying SRv6 and subsequently allocate /64 prefixes for SIDs at
each SRv6 node. The /48 assignment is one sixty-five thousandth
(1/2^16) of the usable IPv6 address space available for assignment by
the provider.</t>
<t>When an operator instantiates a SID at a node, they specify a SID
value B:N:FUNCT and the behavior bound to the SID using one of the
SRv6 Endpoint Behavior codepoints of the registry defined in this
document (see <xref target="endpoint_cp_types"
format="default"/>).</t>
<t>The node advertises the SID, B:N:FUNCT, in the control plane (see
<xref target="cp" format="default"/>) together with the SRv6 Endpoint
Behavior codepoint identifying the behavior of the SID.</t>
<t>An SR source node cannot infer the behavior by examination of the
FUNCT value of a SID.</t>
<t>Therefore, the SRv6 Endpoint Behavior codepoint is advertised along
with the SID in the control plane.</t>
<t>An SR source node uses the SRv6 Endpoint Behavior codepoint to map
the received SID (B:N:FUNCT) to a behavior.</t>
<t>An SR source node selects a desired behavior at an advertising node
by selecting the SID (B:N:FUNCT) advertised with the desired
behavior.</t>
<t>As an example:
</t>
<ul spacing="normal">
<li>A network operator may assign an SRv6 SID block
2001:db8:bbbb::/48 from their in-house operation block for their
SRv6 infrastructure.</li>
<li>A network operator may assign an SRv6 Locator 2001:db8:bbbb:3::/64
to one particular
router, for example Router 3, in their SR Domain.</li>
<li>
<t>The network learns about a path to 2001:db8:b:1::/64 via the <t>At Router 3, within the locator 2001:db8:bbbb:3::/64, the
IGP and hence a packet destined to 2001:db8:b:1:100:: would be routed up to N. T network operator or the router performs dynamic assignment for:
he network does not learn about a path to 2001:db8:b:2::/64 via the IGP and henc </t>
e a packet destined to 2001:db8:b:2:101:: would not be routed up to N.</t>
<t>A packet could be steered through a non-routed SID 2001:db8:b <ul spacing="normal">
:2:101:: by using a SID list &lt;...,2001:db8:b:1:100::,2001:db8:b:2:101::,...&g <li>
t; where the non-routed SID is preceded by a routed SID to the same node. A pack <t>Function 0x0100 associated with the behavior End.X
et could also be steered to a node instantiating a non-routed SID by preceding i (Endpoint with L3 cross-connect) between router 3 and its
t in the SID-list with an Adjacency SID to that node. Routed and non-routed SRv6 connected neighbor router (e.g., Router 4). This function
SIDs are the SRv6 instantiation of global and local segments, respectively <xre is encoded as a 16-bit value and has no arguments (F=16,
f target="RFC8402"/>.<vspace blankLines="25" /></t> A=0).</t>
</section> <t>
</section> This SID is advertised in the control plane as
2001:db8:bbbb:3:100:: with an SRv6 Endpoint
Behavior codepoint value of 5.</t>
</li>
<li>
<t>Function 0x0101 associated with the behavior End.X
(Endpoint with L3 cross-connect) between router 3 and its
connected neighbor router (e.g., Router 2). This function is
encoded as a 16-bit value and has no arguments (F=16, A=0).</t>
<t>
This SID is advertised in the control plane as
2001:db8:bbbb:3:101:: with an SRv6 Endpoint
Behavior codepoint value of 5.</t>
</li>
</ul>
</li>
</ul>
<t>These examples do not preclude any other IPv6 addressing allocation s
cheme.</t>
</section>
<section numbered="true" toc="default">
<name>SID Reachability</name>
<t>Most often, the node N would advertise IPv6 prefix(es) matching the
LOC parts covering its SIDs or shorter-mask prefix. The distribution
of these advertisements and calculation of their reachability are
specific to the routing protocol and are outside of the scope of this
document.</t>
<t>An SRv6 SID is said to be routed if its SID belongs to an IPv6
prefix advertised via a routing protocol. An SRv6 SID that does not
fulfill this condition is non-routed.</t>
<t>Let's provide a classic illustration:</t>
<t>Node N is configured explicitly with two SIDs: 2001:db8:b:1:100:: and
2001:db8:b:2:101::.</t>
<t>The network learns about a path to 2001:db8:b:1::/64 via the IGP;
hence, a packet destined to 2001:db8:b:1:100:: would be routed up
to N. The network does not learn about a path to 2001:db8:b:2::/64 via
the IGP; hence, a packet destined to 2001:db8:b:2:101:: would not be
routed up to N.</t>
<?rfc needLines="40" ?> <t>A packet could be steered through a non-routed SID
<section title="SR Endpoint Behaviors" anchor="behaviors"> 2001:db8:b:2:101:: by using a SID list
<t>Following is a set of well-known behaviors that can be associated &lt;...,2001:db8:b:1:100::,2001:db8:b:2:101::,...&gt; where the
with a SID.</t> non-routed SID is preceded by a routed SID to the same node. A packet
<figure> could also be steered to a node instantiating a non-routed SID by
<artwork><![CDATA[ preceding it in the SID list with an Adj-SID to that
End Endpoint function node. Routed and non-routed SRv6 SIDs are the SRv6 instantiation of
The SRv6 instantiation of a Prefix SID [RFC8402] global and local segments, respectively <xref target="RFC8402"
End.X Endpoint with Layer-3 cross-connect format="default"/>.</t>
The SRv6 instantiation of an Adj SID [RFC8402] </section>
End.T Endpoint with specific IPv6 table lookup </section>
End.DX6 Endpoint with decapsulation and IPv6 cross-connect <section anchor="behaviors" numbered="true" toc="default">
e.g. IPv6-L3VPN (equivalent to per-CE VPN label) <name>SR Endpoint Behaviors</name>
End.DX4 Endpoint with decaps and IPv4 cross-connect <t>The following is a set of well-known behaviors that can be associated w
e.g. IPv4-L3VPN (equivalent to per-CE VPN label) ith a SID.</t>
End.DT6 Endpoint with decapsulation and IPv6 table lookup
e.g. IPv6-L3VPN (equivalent to per-VRF VPN label)
End.DT4 Endpoint with decapsulation and IPv4 table lookup
e.g. IPv4-L3VPN (equivalent to per-VRF VPN label)
End.DT46 Endpoint with decapsulation and IP table lookup
e.g. IP-L3VPN (equivalent to per-VRF VPN label)
End.DX2 Endpoint with decapsulation and L2 cross-connect
e.g. L2VPN use-case
End.DX2V Endpoint with decaps and VLAN L2 table lookup
e.g. EVPN Flexible cross-connect use-case
End.DT2U Endpoint with decaps and unicast MAC L2 table lookup
e.g. EVPN Bridging unicast use-case
End.DT2M Endpoint with decapsulation and L2 table flooding
e.g. EVPN Bridging BUM use-case with ESI filtering
End.B6.Encaps Endpoint bound to an SRv6 policy with encapsulation
SRv6 instantiation of a Binding SID
End.B6.Encaps.Red End.B6.Encaps with reduced SRH
SRv6 instantiation of a Binding SID
End.BM Endpoint bound to an SR-MPLS Policy
SRv6 instantiation of an SR-MPLS Binding SID
]]></artwork>
</figure>
<t>The list is not exhaustive. In practice, any behavior can be atta <table anchor="endpoint">
ched to a local SID: e.g. a node N can bind a SID to a local VM or container whi <name>Endpoint Behaviors</name>
ch can apply any complex processing on the packet, provided there is a behavior
codepoint allocated for the processing.</t>
<t>When an SRv6-capable node (N) receives an IPv6 packet whose desti
nation address matches a FIB entry that represents a locally instantiated SRv6 S
ID (S), the IPv6 header chain is processed as defined in Section 4 of <xref targ
et="RFC8200" />. For SRv6 SIDs associated with an Endpoint Behavior defined in t
his document, the SRH and Upper-layer Header are processed as defined in the fol
lowing subsections.</t>
<t>The pseudocode describing these behaviors details local processin
g at a node. An implementation of the pseudocode is compliant as long as the ext
ernally observable wire protocol is as described by the pseudocode.</t>
<t><xref target="BehFlavors" /> defines flavors of some of these beh <tbody>
aviors.</t> <tr>
<td>End</td>
<td><t>Endpoint</t><t>The SRv6 instantiation of a Prefix-SID <xref target=
"RFC8402"/></t></td>
</tr>
<tr>
<td>End.X</td>
<td><t>Endpoint with L3 cross-connect</t>
<t>The SRv6 instantiation of an Adj-SID <xref target="RFC8402"/>
</t></td>
<t><xref target="iana_registry" /> of this document defines the IANA </tr>
Registry used to maintain all these behaviors as well as future ones defined in <tr>
other documents.</t> <td>End.T</td>
<td>Endpoint with specific IPv6 table lookup</td>
</tr>
<tr>
<td>End.DX6</td>
<td><t>Endpoint with decapsulation and IPv6 cross-connect</t>
<t>e.g., IPv6-L3VPN (equivalent to per-CE VPN label)
</t>
</td>
</tr>
<tr>
<td>End.DX4</td>
<td><t>Endpoint with decapsulation and IPv4 cross-connect</t>
<t>e.g., IPv4-L3VPN (equivalent to per-CE VPN label)
</t>
</td>
</tr>
<tr>
<td>End.DT6</td>
<td><t>Endpoint with decapsulation and specific IPv6 table lookup
</t>
<t>e.g., IPv6-L3VPN (equivalent to per-VRF VPN label)
</t>
</td>
</tr>
<tr>
<td>End.DT4</td>
<td><t>Endpoint with decapsulation and specific IPv4 table lookup</t>
<t>e.g., IPv4-L3VPN (equivalent to per-VRF VPN label)
</t>
</td>
</tr>
<tr>
<td>End.DT46</td>
<td><t>Endpoint with decapsulation and specific IP table lookup</t>
<t>e.g., IP-L3VPN (equivalent to per-VRF VPN label)
</t>
</td>
</tr>
<tr>
<td>End.DX2</td>
<td>
<t>Endpoint with decapsulation and L2 cross-connect
</t>
<t>e.g., L2VPN use case
</t>
</td>
</tr>
<tr>
<td>End.DX2V</td>
<td>
<t>Endpoint with decapsulation and VLAN L2 table lookup
</t>
<t>e.g., EVPN Flexible Cross-connect use case
</t>
</td>
</tr>
<tr>
<td>End.DT2U</td>
<td>
<t>Endpoint with decapsulation and unicast MAC L2 table lookup
</t>
<t>e.g., EVPN Bridging Unicast use case
</t>
</td>
</tr>
<tr>
<td>End.DT2M</td>
<td><t>Endpoint with decapsulation and L2 table flooding</t>
<t>e.g., EVPN Bridging Broadcast, Unknown Unicast, and Multicast (BUM) use
case with Ethernet Segment Identifier (ESI) filtering
</t>
</td>
</tr>
<tr>
<td>End.B6.Encaps</td>
<td><t>Endpoint bound to an SRv6 Policy with encapsulation</t>
<t>SRv6 instantiation of a Binding SID
</t>
</td>
</tr>
<tr>
<td>End.B6.Encaps.Red</td>
<?rfc needLines="40" ?> <td>
<section title="End: Endpoint"> <t>End.B6.Encaps with reduced SRH
</t>
<t>SRv6 instantiation of a Binding SID
</t>
</td>
</tr>
<tr>
<td>End.BM</td>
<td>
<t>Endpoint bound to an SR-MPLS Policy
</t>
<t>SRv6 instantiation of an SR-MPLS Binding SID
</t>
</td>
</tr>
</tbody>
</table>
<t>The Endpoint behavior ("End" for short) is the most basic beh <t>The list is not exhaustive. In practice, any behavior can be attached
avior. It is the instantiation of a Prefix-SID <xref target="RFC8402" />.</t> to a local SID; for example, a node N can bind a SID to a local Virtual
Machine (VM) or container that can apply any complex processing on the
packet, provided there is an SRv6 Endpoint Behavior codepoint allocated
for the processing.</t>
<t>When an SRv6-capable node (N) receives an IPv6 packet whose
destination address matches a FIB entry that represents a locally
instantiated SRv6 SID (S), the IPv6 header chain is processed as defined
in <xref target="RFC8200" sectionFormat="of" section="4" format="default"/
>. For SRv6 SIDs
associated with an Endpoint behavior defined in this document, the SRH
and Upper-Layer header are processed as defined in the following
subsections.</t>
<t>The pseudocode describing these behaviors details local processing at
a node. An implementation of the pseudocode is compliant as long as the
externally observable wire protocol is as described by the
pseudocode.</t>
<t><xref target="BehFlavors" format="default"/> defines flavors of some of
these behaviors.</t>
<t><xref target="iana_registry" format="default"/> of this document
defines the IANA registry used to maintain all these behaviors as well
as future ones defined in other documents.</t>
<t><vspace blankLines="2" />When N receives a packet whose IPv6 <section numbered="true" toc="default">
DA is S and S is a local End SID, N does:</t> <name>End: Endpoint</name>
<t>The Endpoint behavior ("End" for short) is the most basic
behavior. It is the instantiation of a Prefix-SID <xref
target="RFC8402" format="default"/>.</t>
<figure> <t>When N receives a packet whose IPv6 DA is S and S is a local End SID,
<artwork><![CDATA[ N does the following:</t>
<sourcecode type="pseudocode">
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left == 0) { S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by header in the packet, whose type is identified by
the Next Header field in the routing header. the Next Header field in the routing header.
S04. } S04. }
S05. If (IPv6 Hop Limit <= 1) { S05. If (IPv6 Hop Limit &lt;= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address, S06. Send an ICMP Time Exceeded message to the Source Address
Code 0 (Hop limit exceeded in transit), with Code 0 (Hop limit exceeded in transit),
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S07. } S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1 S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) { S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address, S10. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S11. } S11. }
S12. Decrement IPv6 Hop Limit by 1 S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1 S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left] S14. Update IPv6 DA with Segment List[Segments Left]
S15. Submit the packet to the egress IPv6 FIB lookup and S15. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
S16. } S16. }
]]></artwork> </sourcecode>
</figure> <aside>
<t>Notes:<vspace blankLines="0" /> <t>Note:</t>
The End behavior operates on the same FIB table (i.e. identified <t>The End behavior operates on the same FIB table (i.e.,
by VRF or L3 relay id) associated to the packet. Hence the FIB lookup on line S identified by VRF or L3 relay ID) associated to the packet. Hence, the FIB
15 is done in the same FIB table as the ingress interface.</t> lookup on line S15 is done in the same FIB table as the ingress interface.
</t>
</aside>
<section title="Upper-Layer Header" anchor="upper"> <section anchor="upper" numbered="true" toc="default">
<t>When processing the Upper-layer Header of a packet matchi <name>Upper-Layer Header</name>
ng a FIB entry locally instantiated as an End SID, N does:</t> <t>When processing the Upper-Layer header of a packet matching a FIB
<figure> entry locally instantiated as an End SID, N does the following:</t>
<artwork><![CDATA[ <sourcecode type="pseudocode">
S01. If (Upper-Layer Header type is allowed by local configuration) { S01. If (Upper-Layer header type is allowed by local configuration) {
S02. Proceed to process the Upper-layer Header S02. Proceed to process the Upper-Layer header
S03. } Else { S03. } Else {
S04. Send an ICMP Parameter Problem to the Source Address, S04. Send an ICMP Parameter Problem to the Source Address
Code 4 (SR Upper-layer Header Error), with Code 4 (SR Upper-layer Header Error)
Pointer set to the offset of the Upper-layer Header, and Pointer set to the offset of the Upper-Layer header,
Interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S05 } S05 }
]]></artwork> </sourcecode>
</figure> <t>Allowing the processing of specific Upper-Layer header types is
<t>Allowing processing of specific Upper-Layer Headers types useful for Operations, Administration, and Maintenance (OAM). As an
is useful for OAM. As an example, an operator might permit pinging of SIDs. To example, an operator might permit pinging of SIDs. To do this, they
do this they may enable local configuration to allow Upper-layer Header type 58 may enable local configuration to allow Upper-Layer header type 58
(ICMPv6).</t> (ICMPv6).</t>
<t>It is RECOMMENDED that an implementation of local configu <t>It is <bcp14>RECOMMENDED</bcp14> that an implementation of local
ration only allows Upper-layer Header processing of types that do not result in configuration only allows Upper-Layer header processing of types
the packet being forwarded (e.g. ICMPv6).</t> that do not result in the packet being forwarded (e.g., ICMPv6).</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<?rfc needLines="20" ?> <name>End.X: L3 Cross-Connect</name>
<section title="End.X: Layer-3 Cross-Connect"> <t>The "Endpoint with L3 cross-connect" behavior ("End.X" for short) is
<t>The "Endpoint with cross-connect to an array of layer-3 adjac a variant of the End behavior.</t>
encies" behavior (End.X for short) is a variant of the End behavior.</t> <t>It is the SRv6 instantiation of an Adj-SID <xref target="RFC8402" for
mat="default"/>, and its main use is for traffic-engineering policies.</t>
<t>It is the SRv6 instantiation of an Adjacency-SID <xref target <t>Any SID instance of this behavior is associated with a set, J, of
="RFC8402" /> and its main use is for traffic-engineering policies.</t> one or more L3 adjacencies.</t>
<t>When N receives a packet destined to S and S is a local End.X SID, th
<t>Any SID instance of this behavior is associated with a set, J e line S15 from the End processing is replaced by the following:</t>
, of one or more Layer-3 adjacencies.</t> <sourcecode type="pseudocode">
<t><vspace blankLines="2" />When N receives a packet destined to
S and S is a local End.X SID, the line S15 from the End processing is replaced
by the following:</t>
<figure> <artwork><![CDATA[
S15. Submit the packet to the IPv6 module for transmission S15. Submit the packet to the IPv6 module for transmission
to the new destination via a member of J to the new destination via a member of J
]]></artwork> </sourcecode>
</figure>
<t>Notes:<vspace blankLines="0" />
S15. If the set J contains several L3 adjacencies, then one elem
ent of the set is selected based on a hash of the packet's header (see <xref tar
get="OpsFlowLabel" />).</t>
<t><vspace blankLines="2" />If a node N has 30 outgoing interfac
es to 30 neighbors, usually the operator would explicitly instantiate 30 End.X S
IDs at N: one per layer-3 adjacency to a neighbor. Potentially, more End.X coul
d be explicitly defined (groups of layer-3 adjacencies to the same neighbor or t
o different neighbors).</t>
<t>Note that if N has an outgoing interface bundle I to a neighb
or Q made of 10 member links, N might allocate up to 11 End.X local SIDs: one fo
r the bundle itself and then up to one for each Layer-2 member link. The flows s
teered using the End.X SID corresponding to the bundle itself get load balanced
across the member links via hashing while the flows steered using the End.X SID
corresponding to a member link get steered over that specific member link alone.
</t>
<t><vspace blankLines="2" />When the End.X behavior is associate
d with a BGP Next-Hop, it is the SRv6 instantiation of the BGP Peering Segments
<xref target="RFC8402" />.<vspace blankLines="2" /></t>
<t>When processing the Upper-layer Header of a packet matching a
FIB entry locally instantiated as an End.X SID, process the packet as per <xref
target="upper"/>.</t>
</section>
<?rfc needLines="20" ?>
<section title="End.T: Specific IPv6 Table Lookup">
<t>The "Endpoint with specific IPv6 table lookup" behavior (End.
T for short) is a variant of the End behavior.</t>
<t>The End.T behavior is used for multi-table operation in the c <aside>
ore. For this reason, an instance of the End.T behavior is associated with an IP <t>Note:</t>
v6 FIB table T.</t> <t> S15. If the set J contains several L3 adjacencies, then one element
of the set is selected based on a hash of the packet's header (see <xref
target="OpsFlowLabel" format="default"/>).</t>
</aside>
<t>If a node N has 30 outgoing interfaces to 30 neighbors, usually the
operator would explicitly instantiate 30 End.X SIDs at N: one per
L3 adjacency to a neighbor. Potentially, more End.X could be
explicitly defined (groups of L3 adjacencies to the same neighbor
or to different neighbors).</t>
<t><vspace blankLines="2" />When N receives a packet destined to <t>Note that if N has an outgoing interface bundle I to a neighbor Q
S and S is a local End.T SID, the line S15 from the End processing is replaced made of 10 member links, N might allocate up to 11 End.X local SIDs:
by the following:</t> one for the bundle itself and then up to one for each L2 member
link. The flows steered using the End.X SID corresponding to the
bundle itself get load-balanced across the member links via hashing
while the flows steered using the End.X SID corresponding to a member
link get steered over that specific member link alone.</t>
<t>When the End.X behavior is associated with a BGP Next-Hop, it is
the SRv6 instantiation of the BGP peering segments <xref
target="RFC8402" format="default"/>.</t>
<t>When processing the Upper-Layer header of a packet matching a FIB
entry locally instantiated as an End.X SID, process the packet as per
<xref target="upper" format="default"/>.</t>
<figure> <artwork><![CDATA[ </section>
<section numbered="true" toc="default">
<name>End.T: Specific IPv6 Table Lookup</name>
<t>The "Endpoint with specific IPv6 table lookup" behavior ("End.T" for
short) is a variant of the End behavior.</t>
<t>The End.T behavior is used for multi-table operation in the
core. For this reason, an instance of the End.T behavior is associated
with an IPv6 FIB table T.</t>
<t>When N receives a packet destined to S and S is a local End.T SID,
the line S15 from the End processing is replaced by the following:</t>
<sourcecode type="pseudocode">
S15.1. Set the packet's associated FIB table to T S15.1. Set the packet's associated FIB table to T
S15.2. Submit the packet to the egress IPv6 FIB lookup and S15.2. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
]]></artwork> </figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t>When processing the Upper-layer Header of a packet matching a ry locally instantiated as an End.T SID, process the packet as per <xref target=
FIB entry locally instantiated as an End.T SID, process the packet as per <xref "upper" format="default"/>.</t>
target="upper"/>.</t> </section>
</section> <section numbered="true" toc="default">
<name>End.DX6: Decapsulation and IPv6 Cross-Connect</name>
<section title="End.DX6: Decapsulation and IPv6 Cross-Connect"> <t>The "Endpoint with decapsulation and IPv6 cross-connect" behavior ("E
<t>The "Endpoint with decapsulation and cross-connect to an arra nd.DX6" for short) is a variant of the End.X behavior.</t>
y of IPv6 adjacencies" behavior (End.DX6 for short) is a variant of the End.X be <t>One of the applications of the End.DX6 behavior is the L3VPNv6 use ca
havior.</t> se where a FIB lookup in a specific tenant table at the egress Provider Edge (PE
) is not required. This is equivalent to the per-CE VPN label in MPLS <xref targ
<t>One of the applications of the End.DX6 behavior is the L3VPNv et="RFC4364" format="default"/>.</t>
6 use-case where a FIB lookup in a specific tenant table at the egress Provider <t>The End.DX6 SID <bcp14>MUST</bcp14> be the last segment in an SR Poli
Edge (PE) is not required. This is equivalent to the per-CE VPN label in MPLS <x cy, and it is associated with one or more L3 IPv6 adjacencies J.</t>
ref target="RFC4364" />.</t> <t>When N receives a packet destined to S and S is a local End.DX6 SID,
N does the following:</t>
<t>The End.DX6 SID MUST be the last segment in a SR Policy, and <sourcecode type="pseudocode">
it is associated with one or more L3 IPv6 adjacencies J.</t>
<t><vspace blankLines="2" />When N receives a packet destined to
S and S is a local End.DX6 SID, N does:</t>
<figure><artwork><![CDATA[
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DX6 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DX6 SID, N do <sourcecode type="pseudocode">
es:</t> S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 header with all its extension headers
<figure><artwork><![CDATA[
S01. If (Upper-Layer Header type == 41(IPv6) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Forward the exposed IPv6 packet to the L3 adjacency J S03. Forward the exposed IPv6 packet to the L3 adjacency J
S04. } Else { S04. } Else {
S05. Process as per Section 4.1.1 S05. Process as per Section 4.1.1
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>Notes:<vspace blankLines="0" />
S01. 41 refers to IPv6 encapsulation as defined by IANA allocati
on for Internet Protocol Numbers.<vspace blankLines="0" />
S03. If the End.DX6 SID is bound to an array of L3 adjacencies,
then one entry of the array is selected based on the hash of the packet's header
(see <xref target="OpsFlowLabel" />).</t>
</section>
<section title="End.DX4: Decapsulation and IPv4 Cross-Connect"> <aside>
<t>The "Endpoint with decapsulation and cross-connect to an arra <t>Note:</t>
y of IPv4 adjacencies" behavior (End.DX4 for short) is a variant of the End.X be <t>
havior.</t> S01. "41" refers to "IPv6 encapsulation" as defined in the IANA
<t>One of the applications of the End.DX4 behavior is the L3VPNv "Assigned Internet Protocol Numbers" registry.
4 use-case where a FIB lookup in a specific tenant table at the egress PE is not </t>
required. This is equivalent to the per-CE VPN label in MPLS <xref target="RFC4
364" />.</t>
<t>The End.DX4 SID MUST be the last segment in a SR Policy, and
it is associated with one or more L3 IPv4 adjacencies J.</t>
<t><vspace blankLines="2" />When N receives a packet destined to
S and S is a local End.DX4 SID, N does:</t>
<figure><artwork><![CDATA[ <t>
S03. If the End.DX6 SID is bound to an array of L3 adjacencies, then one entry
of the array is selected based on the hash of the packet's header (see <xref
target="OpsFlowLabel" format="default"/>).</t>
</aside>
</section>
<section numbered="true" toc="default">
<name>End.DX4: Decapsulation and IPv4 Cross-Connect</name>
<t>The "Endpoint with decapsulation and IPv4 cross-connect" behavior
("End.DX4" for short) is a variant of the End.X behavior.</t>
<t>One of the applications of the End.DX4 behavior is the L3VPNv4 use
case where a FIB lookup in a specific tenant table at the egress PE is
not required. This is equivalent to the per-CE VPN label in MPLS <xref
target="RFC4364" format="default"/>.</t>
<t>The End.DX4 SID <bcp14>MUST</bcp14> be the last segment in an SR
Policy, and it is associated with one or more L3 IPv4 adjacencies
J.</t>
<t>When N receives a packet destined to S and S is a local End.DX4
SID, N does the following:</t>
<sourcecode type="pseudocode">
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DX4 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DX4 SID, N do <sourcecode type="pseudocode">
es:</t> S01. If (Upper-Layer header type == 4(IPv4) ) {
<figure><artwork><![CDATA[ S02. Remove the outer IPv6 header with all its extension headers
S01. If (Upper-Layer Header type == 4(IPv4) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Forward the exposed IPv4 packet to the L3 adjacency J S03. Forward the exposed IPv4 packet to the L3 adjacency J
S04. } Else { S04. } Else {
S05. Process as per Section 4.1.1 S05. Process as per Section 4.1.1
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>Notes:<vspace blankLines="0" /> <aside>
S01. 4 refers to IPv4 encapsulation as defined by IANA allocatio <t>Note:</t>
n for Internet Protocol Numbers<vspace blankLines="0" /> <t>
S03. If the End.DX4 SID is bound to an array of L3 adjacencies, S01. "4" refers to "IPv4 encapsulation" as defined in the IANA
then one entry of the array is selected based on the hash of the packet's header "Assigned Internet Protocol Numbers" registry.
(see <xref target="OpsFlowLabel" />).</t> </t>
</section> <t>
<section title="End.DT6: Decapsulation and Specific IPv6 Table Looku
p">
<t>The "Endpoint with decapsulation and specific IPv6 table look
up" behavior (End.DT6 for short) is a variant of the End.T behavior.</t>
<t>One of the applications of the End.DT6 behavior is the L3VPNv
6 use-case where a FIB lookup in a specific tenant table at the egress PE is req
uired. This is equivalent to the per-VRF VPN label in MPLS <xref target="RFC4364
" />.</t>
<t>Note that an End.DT6 may be defined for the main IPv6 table i
n which case an End.DT6 supports the equivalent of an IPv6inIPv6 decapsulation (
without VPN/tenant implication).</t>
<t>The End.DT6 SID MUST be the last segment in a SR Policy, and
a SID instance is associated with an IPv6 FIB table T.</t>
<t><vspace blankLines="2" />When N receives a packet destined to S03. If the End.DX4 SID is bound to an array of L3 adjacencies, then one entry
S and S is a local End.DT6 SID, N does:</t> of the array is selected based on the hash of the packet's header (see <xref
<figure><artwork><![CDATA[ target="OpsFlowLabel" format="default"/>).</t>
</aside>
</section>
<section numbered="true" toc="default">
<name>End.DT6: Decapsulation and Specific IPv6 Table Lookup</name>
<t>The "Endpoint with decapsulation and specific IPv6 table lookup"
behavior ("End.DT6" for short) is a variant of the End.T behavior.</t>
<t>One of the applications of the End.DT6 behavior is the
L3VPNv6 use case where a FIB
lookup in a specific tenant table at the egress PE is required. This
is equivalent to the per-VRF VPN label in MPLS <xref target="RFC4364"
format="default"/>.</t>
<t>Note that an End.DT6 may be defined for the main IPv6 table, in
which case an End.DT6 supports the equivalent of an IPv6-in-IPv6
decapsulation (without VPN/tenant implication).</t>
<t>The End.DT6 SID <bcp14>MUST</bcp14> be the last segment in an SR
Policy, and a SID instance is associated with an IPv6 FIB table T.</t>
<t>When N receives a packet destined to S and S is a local End.DT6 SID,
N does the following:</t>
<sourcecode type="pseudocode">
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DT6 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DT6 SID, N do <sourcecode type="pseudocode">
es:</t> S01. If (Upper-Layer header type == 41(IPv6) ) {
<figure><artwork><![CDATA[ S02. Remove the outer IPv6 header with all its extension headers
S01. If (Upper-Layer Header type == 41(IPv6) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Set the packet's associated FIB table to T S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup and S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
S05. } Else { S05. } Else {
S06. Process as per Section 4.1.1 S06. Process as per Section 4.1.1
S07. } S07. }
]]></artwork></figure> </sourcecode>
</section>
</section> <section numbered="true" toc="default">
<name>End.DT4: Decapsulation and Specific IPv4 Table Lookup</name>
<section title="End.DT4: Decapsulation and Specific IPv4 Table Looku <t>The "Endpoint with decapsulation and specific IPv4 table lookup" beha
p"> vior ("End.DT4" for short) is a variant of the End.T behavior.</t>
<t>The "Endpoint with decapsulation and specific IPv4 table look <t>One of the applications of the End.DT4 behavior is the L3VPNv4 use ca
up" behavior (End.DT4 for short) is a variant of the End.T behavior.</t> se where a FIB lookup in a specific tenant table at the egress PE is required. T
<t>One of the applications of the End.DT4 behavior is the L3VPNv his is equivalent to the per-VRF VPN label in MPLS <xref target="RFC4364" format
4 use-case where a FIB lookup in a specific tenant table at the egress PE is req ="default"/>.</t>
uired. This is equivalent to the per-VRF VPN label in MPLS <xref target="RFC4364 <t>Note that an End.DT4 may be defined for the main IPv4 table, in which
" />.</t> case an End.DT4 supports the equivalent of an IPv4-in-IPv6 decapsulation (witho
<t>Note that an End.DT4 may be defined for the main IPv4 table i ut VPN/tenant implication).</t>
n which case an End.DT4 supports the equivalent of an IPv4inIPv6 decapsulation ( <t>The End.DT4 SID <bcp14>MUST</bcp14> be the last segment in an SR Poli
without VPN/tenant implication).</t> cy, and a SID instance is associated with an IPv4 FIB table T.</t>
<t>The End.DT4 SID MUST be the last segment in a SR Policy, and <t>When N receives a packet destined to S and S is a local End.DT4 SID,
a SID instance is associated with an IPv4 FIB table T.</t> N does the following:</t>
<sourcecode type="pseudocode">
<t><vspace blankLines="2" />When N receives a packet destined to
S and S is a local End.DT4 SID, N does:</t>
<figure><artwork><![CDATA[
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DT4 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DT4 SID, N do <sourcecode type="pseudocode">
es:</t> S01. If (Upper-Layer header type == 4(IPv4) ) {
<figure><artwork><![CDATA[ S02. Remove the outer IPv6 header with all its extension headers
S01. If (Upper-Layer Header type == 4(IPv4) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Set the packet's associated FIB table to T S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv4 FIB lookup and S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination transmission to the new destination
S05. } Else { S05. } Else {
S06. Process as per Section 4.1.1 S06. Process as per Section 4.1.1
S07. } S07. }
]]></artwork></figure> </sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="End.DT46: Decapsulation and Specific IP Table Lookup <name>End.DT46: Decapsulation and Specific IP Table Lookup</name>
"> <t>The "Endpoint with decapsulation and specific IP table lookup"
<t>The "Endpoint with decapsulation and specific IP table lookup behavior ("End.DT46" for short) is a variant of the End.DT4 and End.DT6
" behavior (End.DT46 for short) is a variant of the End.DT4 and End.DT6 behavior behavior.</t>
.</t> <t>One of the applications of the End.DT46 behavior is the L3VPN
<t>One of the applications of the End.DT46 behavior is the L3VPN use case where a FIB lookup in a specific IP tenant table at the
use-case where a FIB lookup in a specific IP tenant table at the egress PE is r egress PE is required. This is equivalent to the single per-VRF VPN labe
equired. This is equivalent to single per-VRF VPN label (for IPv4 and IPv6) in M l
PLS<xref target="RFC4364" />.</t> (for IPv4 and IPv6) in MPLS <xref target="RFC4364"
<t>Note that an End.DT46 may be defined for the main IP table in format="default"/>.</t>
which case an End.DT46 supports the equivalent of an IPinIPv6 decapsulation(wit <t>Note that an End.DT46 may be defined for the main IP table, in which
hout VPN/tenant implication).</t> case an End.DT46 supports the equivalent of an IP-in-IPv6
<t>The End.DT46 SID MUST be the last segment in a SR Policy, and decapsulation (without VPN/tenant implication).</t>
a SID instance is associated with an IPv4 FIB table T4 and an IPv6 FIB table T6 <t>The End.DT46 SID <bcp14>MUST</bcp14> be the last segment in an SR
.</t> Policy, and a SID instance is associated with an IPv4 FIB table T4 and
<t><vspace blankLines="2" />When N receives a packet destined to an IPv6 FIB table T6.</t>
S and S is a local End.DT46 SID, N does:</t> <t>When N receives a packet destined to S and S is a local End.DT46
<figure><artwork><![CDATA[ SID, N does the following:</t>
<sourcecode type="pseudocode">
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DT46 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DT46 SID, N d <sourcecode type="pseudocode">
oes:</t> S01. If (Upper-Layer header type == 4(IPv4) ) {
<figure><artwork><![CDATA[ S02. Remove the outer IPv6 header with all its extension headers
S01. If (Upper-layer Header type == 4(IPv4) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Set the packet's associated FIB table to T4 S03. Set the packet's associated FIB table to T4
S04. Submit the packet to the egress IPv4 FIB lookup and S04. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination transmission to the new destination
S05. } Else if (Upper-layer Header type == 41(IPv6) ) { S05. } Else if (Upper-Layer header type == 41(IPv6) ) {
S06. Remove the outer IPv6 Header with all its extension headers S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T6 S07. Set the packet's associated FIB table to T6
S08. Submit the packet to the egress IPv6 FIB lookup and S08. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
S09. } Else { S09. } Else {
S10. Process as per Section 4.1.1 S10. Process as per Section 4.1.1
S11. } S11. }
]]></artwork></figure> </sourcecode>
</section> </section>
<section numbered="true" toc="default">
<section title="End.DX2: Decapsulation and L2 Cross-Connect"> <name>End.DX2: Decapsulation and L2 Cross-Connect</name>
<t>The "Endpoint with decapsulation and Layer-2 cross-connect to <t>The "Endpoint with decapsulation and L2 cross-connect" behavior
an outgoing L2 interface (OIF)" (End.DX2 for short) is a variant of the endpoin ("End.DX2" for short) is a variant of the Endpoint behavior.</t>
t behavior.</t> <t>One of the applications of the End.DX2 behavior is the L2VPN <xref ta
<t>One of the applications of the End.DX2 behavior is the L2VPN rget="RFC4664" format="default"/> / EVPN Virtual Private Wire Service (VPWS) <xr
<xref target="RFC4664" /> / EVPN VPWS <xref target="RFC7432" /> <xref target="RF ef target="RFC7432" format="default"/> <xref target="RFC8214" format="default"/>
C8214" /> use-case.</t> use case.</t>
<t>The End.DX2 SID MUST be the last segment in a SR Policy, and <t>The End.DX2 SID <bcp14>MUST</bcp14> be the last segment in an SR Poli
it is associated with one outgoing interface I.</t> cy, and it is associated with one outgoing interface I.</t>
<t>When N receives a packet destined to S and S is a local End.DX2 SID,
<t><vspace blankLines="2" />When N receives a packet destined to N does the following:</t>
S and S is a local End.DX2 SID, N does:</t> <sourcecode type="pseudocode">
<figure><artwork><![CDATA[
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left != 0) { S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address, S03. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S04. } S04. }
S05. Proceed to process the next header in the packet S05. Proceed to process the next header in the packet
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.DX2 SID, N does the following:</t>
er of a packet matching a FIB entry locally instantiated as an End.DX2 SID, N do <sourcecode type="pseudocode">
es:</t> S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 header with all its extension headers
<figure><artwork><![CDATA[
S01. If (Upper-Layer Header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Forward the Ethernet frame to the OIF I S03. Forward the Ethernet frame to the OIF I
S04. } Else { S04. } Else {
S05. Process as per Section 4.1.1 S05. Process as per Section 4.1.1
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>Notes:<vspace blankLines="0" />
S01. IANA has allocated the Internet Protocol number 143 to Ethe
rnet <xref target="IEEE.802.3_2018"/> (see <xref target="ianaethernet" />).<vspa
ce blankLines="0" />
S03. An End.DX2 behavior could be customized to expect a specifi
c IEEE header (e.g. VLAN tag) and rewrite the egress IEEE header before forwardi
ng on the outgoing interface.</t>
<t><vspace blankLines="2" />Note that an End.DX2 SID may also be
associated with a bundle of outgoing interfaces.</t>
</section>
<section title="End.DX2V: Decapsulation and VLAN L2 Table Lookup">
<t>The "Endpoint with decapsulation and specific VLAN table look
up" behavior (End.DX2V for short) is a variant of the End.DX2 behavior.</t>
<t>One of the applications of the End.DX2V behavior is the EVPN
Flexible cross-connect use-case. The End.DX2V behavior is used to perform a look
up of the Ethernet frame VLANs in a particular L2 table. Any SID instance of thi
s behavior is associated with an L2 Table T.</t>
<t><vspace blankLines="2" />When N receives a packet whose IPv6 <aside>
DA is S and S is a local End.DX2 SID, the processing is identical to the End.DX2 <t>Note:</t> <t>S01. IANA has allocated value "143" for "Ethernet"
behavior except for the Upper-layer header processing which is modified as foll <xref target="IEEE.802.3_2018" format="default"/> in the "Assigned
ows:</t> Internet Protocol Numbers" registry (see <xref target="ianaethernet"
format="default"/>). </t>
<t>
S03. An End.DX2 behavior could be customized to expect a specific IEEE header
(e.g., VLAN tag) and rewrite the egress IEEE header before forwarding on the
outgoing interface.</t>
</aside>
<t>Note that an End.DX2 SID may also be associated with a bundle of
outgoing interfaces.</t>
</section>
<section numbered="true" toc="default">
<name>End.DX2V: Decapsulation and VLAN L2 Table Lookup</name>
<figure><artwork><![CDATA[ <t>The "Endpoint with decapsulation and VLAN L2 table lookup" behavior
S03. Lookup the exposed VLANs in L2 table T, and forward ("End.DX2V" for short) is a variant of the End.DX2 behavior.</t>
<t>One of the applications of the End.DX2V behavior is the EVPN
Flexible Cross-connect use case. The End.DX2V behavior is used to
perform a lookup of the Ethernet frame VLANs in a particular L2
table. Any SID instance of this behavior is associated with an L2
table T.</t>
<t>When N receives a packet whose IPv6 DA is S and S is a local
End.DX2 SID, the processing is identical to the End.DX2 behavior
except for the Upper-Layer header processing, which is modified as
follows:</t>
<sourcecode type="pseudocode">
S03. Look up the exposed VLANs in L2 table T, and forward
via the matched table entry. via the matched table entry.
]]></artwork></figure> </sourcecode>
<t>Notes:<vspace blankLines="0" /> <aside>
S03. An End.DX2V behavior could be customized to expect a specif <t>Note:</t>
ic VLAN format and rewrite the egress VLAN header before forwarding on the outgo <t> S03. An End.DX2V behavior could be customized to expect a specific VLAN
ing interface.</t> format and rewrite the egress VLAN header before forwarding on the outgoing
</section> interface.</t>
</aside>
<section title="End.DT2U: Decapsulation and Unicast MAC L2 Table Loo </section>
kup"> <section numbered="true" toc="default">
<t>The "Endpoint with decapsulation and specific unicast MAC L2 <name>End.DT2U: Decapsulation and Unicast MAC L2 Table Lookup</name>
table lookup" behavior (End.DT2U for short) is a variant of the End behavior.</t <t>The "Endpoint with decapsulation and unicast MAC L2 table lookup"
> behavior ("End.DT2U" for short) is a variant of the End behavior.</t>
<t>One of the applications of the End.DT2U behavior is the EVPN
<t>One of the applications of the End.DT2U behavior is the EVPN Bridging Unicast <xref target="RFC7432" format="default"/>. Any SID
Bridging unicast <xref target="RFC7432" />. Any SID instance of the End.DT2U beh instance of the End.DT2U behavior is associated with an L2 table
avior is associated with an L2 Table T.</t> T.</t>
<t>When N receives a packet whose IPv6 DA is S and S is a local
<t><vspace blankLines="2" />When N receives a packet whose IPv6 End.DT2U SID, the processing is identical to the End.DX2 behavior
DA is S and S is a local End.DT2U SID, the processing is identical to the End.DX except for the Upper-Layer header processing, which is as follows:</t>
2 behavior except for the Upper-layer header processing which is as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="pseudocode">
S01. If (Upper-Layer Header type == 143(Ethernet) ) { S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 Header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 Table T S03. Learn the exposed MAC Source Address in L2 table T
S04. Lookup the exposed MAC Destination Address in L2 Table T S04. Look up the exposed MAC Destination Address in L2 table T
S05. If (matched entry in T) { S05. If (matched entry in T) {
S06. Forward via the matched table T entry S06. Forward via the matched table T entry
S07. } Else { S07. } Else {
S08. Forward via all L2 OIFs entries in table T S08. Forward via all L2 OIFs in table T
S09. } S09. }
S10. } Else { S10. } Else {
S11. Process as per Section 4.1.1 S11. Process as per Section 4.1.1
S12. } S12. }
]]></artwork></figure> </sourcecode>
<aside>
<t>Notes:<vspace blankLines="0" /> <t>Note:</t> <t>S01. IANA has allocated value "143" for "Ethernet" in
S01. IANA has allocated the Internet Protocol number 143 to Ethe the "Assigned Internet Protocol Numbers" registry (see <xref
rnet (see <xref target="ianaethernet" />).<vspace blankLines="0" /> target="ianaethernet" format="default"/>).
S03. In EVPN <xref target="RFC7432" />, the learning of the expo </t>
sed MAC Source Address is done via control plane. In L2VPN VPLS <xref target="RF <t>
C4761" /> <xref target="RFC4762" /> reachability is obtained by standard learnin S03. In EVPN <xref target="RFC7432" format="default"/>, the learning of the
g bridge functions in the data plane.</t> exposed MAC Source Address is done via the control plane. In L2VPN Virtual Priva
</section> te LAN Service (VPLS) <xref
target="RFC4761" format="default"/> <xref target="RFC4762" format="default"/>,
<section title="End.DT2M: Decapsulation and L2 Table Flooding"> reachability is obtained by standard learning bridge functions in the data
<t>The "Endpoint with decapsulation and specific L2 table floodi plane.</t>
ng" behavior (End.DT2M for short) is a variant of the End.DT2U behavior.</t> </aside>
</section>
<t>Two of the applications of the End.DT2M behavior are the EVPN
Bridging of broadcast, unknown and multicast (BUM) traffic with Ethernet Segmen
t Identifier (ESI) filtering <xref target="RFC7432" /> and the EVPN ETREE <xref
target="RFC8317"/>use-cases.</t>
<t>Any SID instance of this behavior is associated with a L2 tab
le T. The behavior also takes an argument: "Arg.FE2". This argument provides a l
ocal mapping to ESI for split-horizon filtering of the received traffic to exclu
de specific OIF (or set of OIFs) from L2 table T flooding. The allocation of the
argument values is local to the SR Endpoint Node instantiating this behavior an
d the signaling of the argument to other nodes for the EVPN functionality occurs
via control plane.</t>
<t><vspace blankLines="2" />When N receives a packet whose IPv6 <section numbered="true" toc="default">
DA is S and S is a local End.DT2M SID, the processing is identical to the End.DX <name>End.DT2M: Decapsulation and L2 Table Flooding</name>
2 behavior except for the Upper-layer header processing which is as follows:</t> <t>The "Endpoint with decapsulation and L2 table flooding" behavior
("End.DT2M" for short) is a variant of the End.DT2U behavior.</t>
<t>Two of the applications of the End.DT2M behavior are the EVPN
Bridging of Broadcast, Unknown Unicast, and Multicast (BUM) traffic
with Ethernet Segment Identifier (ESI) filtering <xref
target="RFC7432" format="default"/> and the EVPN Ethernet-Tree
(E-Tree) <xref target="RFC8317" format="default"/> use cases.</t>
<t>Any SID instance of this behavior is associated with an L2 table
T. The behavior also takes an argument: "Arg.FE2". This argument
provides a local mapping to ESI for split-horizon filtering of the
received traffic to exclude a specific OIF (or set of OIFs) from L2
table T flooding. The allocation of the argument values is local to
the SR Segment Endpoint Node instantiating this behavior, and the signal
ing of
the argument to other nodes for the EVPN functionality occurs via the
control plane.</t>
<t>When N receives a packet whose IPv6 DA is S and S is a local
End.DT2M SID, the processing is identical to the End.DX2 behavior
except for the Upper-Layer header processing, which is as follows:</t>
<figure><artwork><![CDATA[ <sourcecode type="pseudocode">
S01. If (Upper-Layer Header type == 143(Ethernet) ) { S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02. Remove the outer IPv6 Header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Learn the exposed MAC Source Address in L2 Table T S03. Learn the exposed MAC Source Address in L2 table T
S04. Forward via all L2OIFs excluding those associated by the S04. Forward via all L2 OIFs excluding those associated with the
identifier Arg.FE2 identifier Arg.FE2
S05. } Else { S05. } Else {
S06. Process as per Section 4.1.1 S06. Process as per Section 4.1.1
S07. } S07. }
]]></artwork></figure> </sourcecode>
<t>Notes:<vspace blankLines="0" /> <aside>
S01. IANA has allocated the Internet Protocol number 143 to Ethe <t>Note:</t>
rnet (see <xref target="ianaethernet" />).<vspace blankLines="0" />
S03. In EVPN <xref target="RFC7432" />, the learning of the expo
sed MAC Source Address is done via control plane. In L2VPN VPLS <xref target="RF
C4761" /> <xref target="RFC4762" /> reachability is obtained by standard learnin
g bridge functions in the data plane.</t>
</section>
<section title="End.B6.Encaps: Endpoint Bound to an SRv6 Policy w/ E
ncaps">
<t>This is a variation of the End behavior.</t>
<t>One of its applications is to express scalable traffic-engine
ering policies across multiple domains. It is one of the SRv6 instantiations of
a Binding SID <xref target="RFC8402" />.</t>
<t>Any SID instance of this behavior is associated with an SR Po
licy B and a source address A.</t>
<t><vspace blankLines="2" />When N receives a packet whose IPv6 <t>S01. IANA has allocated value "143" for "Ethernet" in
DA is S and S is a local End.B6.Encaps SID, N does:</t> the "Assigned Internet Protocol Numbers" registry (see <xref
<figure><artwork><![CDATA[ target="ianaethernet" format="default"/>).
</t>
<t>
S03. In EVPN <xref target="RFC7432" format="default"/>, the learning of the
exposed MAC Source Address is done via the control plane. In L2VPN VPLS <xref
target="RFC4761" format="default"/> <xref target="RFC4762" format="default"/>,
reachability is obtained by standard learning bridge functions in the data
plane.</t>
</aside>
</section>
<section numbered="true" toc="default">
<name>End.B6.Encaps: Endpoint Bound to an SRv6 Policy with Encapsulation
</name>
<t>This is a variation of the End behavior.</t>
<t>One of its applications is to express scalable traffic-engineering po
licies across multiple domains. It is one of the SRv6 instantiations of a Bindin
g SID <xref target="RFC8402" format="default"/>.</t>
<t>Any SID instance of this behavior is associated with an SR Policy B a
nd a source address A.</t>
<t>When N receives a packet whose IPv6 DA is S and S is a local End.B6.E
ncaps SID, N does the following:</t>
<sourcecode type="pseudocode">
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left == 0) { S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by header in the packet, whose type is identified by
the Next Header field in the routing header. the Next Header field in the routing header.
S04. } S04. }
S05. If (IPv6 Hop Limit <= 1) { S05. If (IPv6 Hop Limit &lt;= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address, S06. Send an ICMP Time Exceeded message to the Source Address
Code 0 (Hop limit exceeded in transit), with Code 0 (Hop limit exceeded in transit),
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S07. } S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1 S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address, S10. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S11. } S11. }
S12. Decrement IPv6 Hop Limit by 1 S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1 S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left] S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push a new IPv6 header with its own SRH containing B S15. Push a new IPv6 header with its own SRH containing B
S16. Set the outer IPv6 SA to A S16. Set the outer IPv6 SA to A
S17. Set the outer IPv6 DA to the first SID of B S17. Set the outer IPv6 DA to the first SID of B
S18. Set the outer Payload Length, Traffic Class, Flow Label, S18. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit and Next-Header fields Hop Limit, and Next Header fields
S19. Submit the packet to the egress IPv6 FIB lookup and S19. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
S20. } S20. }
]]></artwork></figure> </sourcecode>
<aside>
<t>Notes:<vspace blankLines="0" /> <t>Note:</t>
S15. The SRH MAY be omitted when the SRv6 Policy B only contains <t>
one SID and there is no need to use any flag, tag or TLV.<vspace blankLines="0" S15. The SRH <bcp14>MAY</bcp14> be omitted when the SRv6 Policy
/> B only contains one SID and there is no need to use any flag, tag, or TLV.
S18. The Payload Length, Traffic Class, Hop Limit and Next-Heade </t>
r fields are set as per <xref target="RFC2473" />. The Flow Label is computed as
per <xref target="RFC6437" />.</t>
<t><vspace blankLines="2" />When processing the Upper-layer head
er of a packet matching a FIB entry locally instantiated as an End.B6.Encaps SID
, process the packet as per <xref target="upper"/>.<vspace blankLines="3" /></t>
</section>
<section title="End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH">
<t>This is an optimization of the End.B6.Encaps behavior.</t>
<t>End.B6.Encaps.Red reduces the size of the SRH by one SID by e
xcluding the first SID in the SRH of the new IPv6 header. Thus, the first segmen
t is only placed in the IPv6 Destination Address of the new IPv6 header and the
packet is forwarded according to it.</t>
<t>The SRH Last Entry field is set as defined in Section 4.1.1 o
f <xref target="RFC8754" />.</t>
<t>The SRH MAY be omitted when the SRv6 Policy only contains one
SID and there is no need to use any flag, tag or TLV.</t>
</section>
<section title="End.BM: Endpoint Bound to an SR-MPLS Policy"> <t>
<t>The "Endpoint bound to an SR-MPLS Policy" is a variant of the S18. The Payload Length, Traffic Class, Hop Limit, and Next Header fields are se
End behavior.</t> t as per <xref target="RFC2473" format="default"/>. The Flow Label is computed a
<t>The End.BM behavior is required to express scalable traffic-e s per <xref target="RFC6437" format="default"/>.</t>
ngineering policies across multiple domains where some domains support the MPLS </aside>
instantiation of Segment Routing. This is an SRv6 instantiation of an SR-MPLS Bi <t>When processing the Upper-Layer header of a packet matching a FIB
nding SID <xref target="RFC8402" />.</t> entry locally instantiated as an End.B6.Encaps SID, process the packet
<t>Any SID instance of this behavior is associated with an SR-MP as per <xref target="upper" format="default"/>.</t>
LS Policy B.</t> </section>
<section numbered="true" toc="default">
<name>End.B6.Encaps.Red: End.B6.Encaps with Reduced SRH</name>
<t>This is an optimization of the End.B6.Encaps behavior.</t>
<t>End.B6.Encaps.Red reduces the size of the SRH by one SID by excluding
the first SID in the SRH of the new IPv6 header. Thus, the first segment is onl
y placed in the IPv6 Destination Address of the new IPv6 header, and the packet
is forwarded according to it.</t>
<t>The SRH Last Entry field is set as defined in <xref
sectionFormat="of" section="4.1.1" target="RFC8754"
format="default"/>.</t>
<t>The SRH <bcp14>MAY</bcp14> be omitted when the SRv6 Policy only conta
ins one SID and there is no need to use any flag, tag, or TLV.</t>
</section>
<section numbered="true" toc="default">
<name>End.BM: Endpoint Bound to an SR-MPLS Policy</name>
<t>The "Endpoint bound to an SR-MPLS Policy" behavior ("End.BM" for shor
t) is a variant of the End behavior.</t>
<t>The End.BM behavior is required to express scalable traffic-engineeri
ng policies across multiple domains where some domains support the MPLS instanti
ation of Segment Routing. This is an SRv6 instantiation of an SR-MPLS Binding SI
D <xref target="RFC8402" format="default"/>.</t>
<t>Any SID instance of this behavior is associated with an SR-MPLS Polic
y B.</t>
<t>When N receives a packet whose IPv6 DA is S and S is a local End.BM S
ID, N does the following:</t>
<t><vspace blankLines="2" />When N receives a packet whose IPv6 <sourcecode type="pseudocode">
DA is S and S is a local End.BM SID, N does:</t>
<figure><artwork><![CDATA[
S01. When an SRH is processed { S01. When an SRH is processed {
S02. If (Segments Left == 0) { S02. If (Segments Left == 0) {
S03. Stop processing the SRH, and proceed to process the next S03. Stop processing the SRH, and proceed to process the next
header in the packet, whose type is identified by header in the packet, whose type is identified by
the Next Header field in the routing header. the Next Header field in the routing header.
S04. } S04. }
S05. If (IPv6 Hop Limit <= 1) { S05. If (IPv6 Hop Limit &lt;= 1) {
S06. Send an ICMP Time Exceeded message to the Source Address, S06. Send an ICMP Time Exceeded message to the Source Address
Code 0 (Hop limit exceeded in transit), with Code 0 (Hop limit exceeded in transit),
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S07. } S07. }
S08. max_LE = (Hdr Ext Len / 2) - 1 S08. max_LE = (Hdr Ext Len / 2) - 1
S09. If ((Last Entry > max_LE) or (Segments Left > (Last Entry+1)) { S09. If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {
S10. Send an ICMP Parameter Problem to the Source Address, S10. Send an ICMP Parameter Problem to the Source Address
Code 0 (Erroneous header field encountered), with Code 0 (Erroneous header field encountered)
Pointer set to the Segments Left field, and Pointer set to the Segments Left field,
interrupt packet processing and discard the packet. interrupt packet processing, and discard the packet.
S11. } S11. }
S12. Decrement IPv6 Hop Limit by 1 S12. Decrement IPv6 Hop Limit by 1
S13. Decrement Segments Left by 1 S13. Decrement Segments Left by 1
S14. Update IPv6 DA with Segment List[Segments Left] S14. Update IPv6 DA with Segment List[Segments Left]
S15. Push the MPLS label stack for B S15. Push the MPLS label stack for B
S16. Submit the packet to the MPLS engine for transmission S16. Submit the packet to the MPLS engine for transmission
S17. } S17. }
]]></artwork></figure> </sourcecode>
<t>When processing the Upper-Layer header of a packet matching a FIB ent
<t><vspace blankLines="2" />When processing the Upper-layer head ry locally instantiated as an End.BM SID, process the packet as per <xref target
er of a packet matching a FIB entry locally instantiated as an End.BM SID, proce ="upper" format="default"/>.</t>
ss the packet as per <xref target="upper"/>.</t> </section>
</section> <section anchor="BehFlavors" numbered="true" toc="default">
<name>Flavors</name>
<section title="Flavors" anchor="BehFlavors"> <t>The Penultimate Segment Pop (PSP) of the SRH, Ultimate Segment Pop (U
<t>The Penultimate Segment Pop of the SRH (PSP), Ultimate Segmen SP) of the SRH, and Ultimate Segment Decapsulation (USD) flavors are variants of
t Pop of the SRH (USP) and Ultimate Segment Decapsulation (USD) flavors are vari the End, End.X, and End.T behaviors. The End, End.X, and End.T behaviors can su
ants of the End, End.X and End.T behaviors. The End, End.X and End.T behaviors c pport these flavors either individually or in combinations.</t>
an support these flavors either individually or in combinations.</t> <section numbered="true" toc="default">
<name>PSP: Penultimate Segment Pop of the SRH</name>
<section numbered="true" toc="default">
<name>Guidelines</name>
<section title="PSP: Penultimate Segment Pop of the SRH"> <t>SR Segment Endpoint Nodes advertise the SIDs instantiated on
<section title="Guidelines"> them via control-plane protocols as described in <xref target="cp"
<t>SR Segment Endpoint Nodes advertise the SIDs instanti format="default"/>. Different behavior IDs are allocated for
ated on them via control plane protocols as described in <xref target="cp" />. D flavored and unflavored SIDs (see <xref target="endpoint_cp_types"
ifferent behavior ids are allocated for flavored and unflavored SIDs (see <xref format="default"/>).</t>
target="endpoint_cp_types" />).</t> <t>An SR Segment Endpoint Node that offers both PSP- and
<t>An SR Segment Endpoint Node that offers both PSP and non-PSP-flavored behavior advertises them as two different
non-PSP flavored behavior advertises them as two different SIDs.</t> SIDs.</t>
<t>The SR Segment Endpoint Node only advertises the PSP <t>The SR Segment Endpoint Node only advertises the PSP flavor if
flavor if the operator enables this capability at the node.</t> the operator enables this capability at the node.</t>
<t>The PSP operation is deterministically controlled by <t>The PSP operation is deterministically controlled by the SR
the SR Source Node.</t> source node.</t>
<t>A PSP-flavored SID is used by the Source SR Node when <t>A PSP-flavored SID is used by the SR source node when it needs
it needs to instruct the penultimate SR Segment Endpoint Node listed in the SRH to instruct the penultimate SR Segment Endpoint Node listed in the
to remove the SRH from the IPv6 header.</t> SRH to remove the SRH from the IPv6 header.</t>
</section> </section>
<section title="Definition"> <section numbered="true" toc="default">
<t>SR Segment Endpoint Nodes receive the IPv6 packet wit <name>Definition</name>
h the Destination Address field of the IPv6 Header equal to its SID address.</t> <t>SR Segment Endpoint Nodes receive the IPv6 packet with the
<t>A penultimate SR Segment Endpoint Node is one that, a Destination Address field of the IPv6 header equal to its SID
s part of the SID processing, copies the last SID from the SRH into the IPv6 Des address.</t>
tination Address and decrements the Segments Left value from one to zero.</t> <t>A penultimate SR Segment Endpoint Node is one that, as part of
<t>The PSP operation only takes place at a penultimate S the SID processing, copies the last SID from the SRH into the IPv6
R Segment Endpoint Node and does not happen at any Transit Node. When a SID of P Destination Address and decrements the Segments Left value from
SP-flavor is processed at a non-penultimate SR Segment Endpoint Node, the PSP be one to zero.</t>
havior is not performed as described in the pseudocode below since Segments Left <t>The PSP operation only takes place at a penultimate SR Segment
would not be zero.</t> Endpoint Node and does not happen at any transit node. When a SID
<t>The SRH processing of the End, End.X and End.T behavi of PSP flavor is processed at a non-penultimate SR Segment
ors are modified: after the instruction "S14. Update IPv6 DA with Segment List[S Endpoint Node, the PSP behavior is not performed as described in
egments Left]" is executed, the following instructions must be executed as well: the pseudocode below since Segments Left would not be zero.</t>
</t> <t>The SRH processing of the End, End.X, and End.T behaviors are
<figure><artwork><![CDATA[ modified: after the instruction "S14. Update IPv6 DA with Segment
List[Segments Left]" is executed, the following instructions must
be executed as well:</t>
<sourcecode type="pseudocode">
S14.1. If (Segments Left == 0) { S14.1. If (Segments Left == 0) {
S14.2. Update the Next Header field in the preceding header to the S14.2. Update the Next Header field in the preceding header to
Next Header value from the SRH the Next Header value from the SRH
S14.3. Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1) S14.3. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S14.4. Remove the SRH from the IPv6 extension header chain S14.4. Remove the SRH from the IPv6 extension header chain
S14.5. } S14.5. }
]]></artwork></figure> </sourcecode>
<t>The usage of PSP does not increase the MTU of the IPv6 packet
and hence does not have any impact on the Path MTU (PMTU)
discovery mechanism.</t>
<t>As a reminder, <xref target="RFC8754" sectionFormat="of"
section="5" format="default"/> defines the SR Deployment Model
within the SR Domain <xref target="RFC8402"
format="default"/>. Within this framework, the Authentication
Header (AH) is not used to secure the SRH as described in <xref
target="RFC8754" sectionFormat="of" section="7.5"
format="default"/>. Hence, the discussion of applicability of PSP
along with AH usage is beyond the scope of this document.</t>
<t>In the context of this specification, the End, End.X, and End.T
behaviors with PSP do not contravene <xref target="RFC8200"
sectionFormat="of" section="4" format="default"/> because the
destination address of the incoming packet is the address of the
node executing the behavior.</t>
</section>
<t>The usage of PSP does not increase the MTU of the IPv <section numbered="true" toc="default">
6 packet and hence does not have any impact on the PMTU discovery mechanism.</t>
<t>As a reminder, <xref target="RFC8754"/> defines in se
ction 5 the SR Deployment Model within the SR Domain <xref target="RFC8402"/>. W
ithin this framework, the Authentication Header (AH) is not used to secure the S
RH as described in Section 7.5 of <xref target="RFC8754"/>. Hence, the discussio
n of applicability of PSP along with AH usage is beyond the scope of this docume
nt.</t>
<t>In the context of this specification, the End, End.X <name>Use Case</name>
and End.T behaviors with PSP do not contravene Section 4 of <xref target="RFC820
0"/> because the destination address of the incoming packet is the address of th <t>One use case for the PSP functionality is streamlining the operat
e node executing the behavior.</t> ion of an egress border router.</t>
</section> <figure anchor="fig-psp">
<section title="Use-case"> <name>PSP Use Case Topology</name>
<t>One use-case for the PSP functionality is streamlinin <artwork name="" type="" align="left" alt=""><![CDATA[
g the operation of an egress border router.</t>
<figure title="PSP use-case topology" anchor="fig-psp"><
artwork><![CDATA[
+----------------------------------------------------+ +----------------------------------------------------+
| | | |
+-+-+ +--+ +--+ +--+ +-+-+ +-+-+ +--+ +--+ +--+ +-+-+
|iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE| |iPE+-------->+R2+-------->+R3+-------->+R4+-------->+ePE|
| R1| +--+ +--+ +--+ |R5 | | R1| +--+ +--+ +--+ |R5 |
+-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+ +-+-+ +-----+ +-----+ +-----+ +-----+ +-+-+
| |IPv6 | |IPv6 | |IPv6 | |IPv6 | | | |IPv6 | |IPv6 | |IPv6 | |IPv6 | |
| |DA=R3| |DA=R3| |DA=R5| |DA=R5| | | |DA=R3| |DA=R3| |DA=R5| |DA=R5| |
| +-----+ +-----+ +-----+ +-----+ | | +-----+ +-----+ +-----+ +-----+ |
| | SRH | | SRH | | IP | | IP | | | | SRH | | SRH | | IP | | IP | |
| |SL=1 | |SL=1 | +-----+ +-----+ | | |SL=1 | |SL=1 | +-----+ +-----+ |
| | R5 | | R5 | | | | R5 | | R5 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | IP | | IP | | | | IP | | IP | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | |
+----------------------------------------------------+ +----------------------------------------------------+
]]></artwork></figure> ]]></artwork>
</figure>
<t>In the above illustration, for a packet sent from iPE
to ePE, node R3 is an intermediate traffic engineering waypoint and is the penu
ltimate segment endpoint router; the node that copies the last segment from the
SRH into the IPv6 Destination Address and decrements segments left to 0. The SDN
controller knows that no other node after R3 needs to inspect the SRH, and it i
nstructs R3 to remove the exhausted SRH from the packet by using a PSP-flavored
SID.</t>
<t>The benefits for the egress PE are straightforward:
<list style="format -">
<t>as part of the decapsulation process the egre
ss PE is required to parse and remove fewer bytes from the packet.</t>
<t>if a lookup on an upper-layer IP header is re
quired (e.g. per-VRF VPN), the header is more likely to be within the memory acc
essible to the lookup engine in the forwarding ASIC (Application-specific integr
ated circuit).</t>
</list>
</t>
</section>
</section>
<section title="USP: Ultimate Segment Pop of the SRH"> <t>In the above illustration, for a packet sent from the ingress
<t>The SRH processing of the End, End.X and End.T behaviors provider edge (iPE) to the egress provider edge (ePE), node R3 is an
are modified: the instructions S02-S04 are substituted by the following ones:</t intermediate traffic-engineering waypoint and is the penultimate
> segment endpoint router; this node copies the last segment from the
<figure><artwork><![CDATA[ SRH into the IPv6 Destination Address and decrements Segments Left to
0. The Software-Defined Networking (SDN) controller knows that no
other node after R3 needs to inspect the SRH, and it instructs R3 to
remove the exhausted SRH from the packet by using a PSP-flavored
SID.</t>
<t>The benefits for the egress PE are straightforward:
</t>
<ul spacing="normal"><li>As part of the decapsulation process, the
egress PE is required to parse and remove fewer bytes from the
packet.</li>
<li>If a lookup on an upper-layer IP header is required (e.g.,
per-VRF VPN), the header is more likely to be within the memory
accessible to the lookup engine in the forwarding ASIC
(Application-Specific Integrated Circuit).</li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>USP: Ultimate Segment Pop of the SRH</name>
<t>The SRH processing of the End, End.X, and End.T behaviors are modif
ied; the instructions S02-S04 are substituted by the following ones:</t>
<sourcecode type="pseudocode">
S02. If (Segments Left == 0) { S02. If (Segments Left == 0) {
S03.1. Update the Next Header field in the preceding header to the S03.1. Update the Next Header field in the preceding header to
Next Header value of the SRH the Next Header value of the SRH
S03.2. Decrease the IPv6 header Payload Length by 8*(Hdr Ext Len+1) S03.2. Decrease the IPv6 header Payload Length by
8*(Hdr Ext Len+1)
S03.3. Remove the SRH from the IPv6 extension header chain S03.3. Remove the SRH from the IPv6 extension header chain
S03.4. Proceed to process the next header in the packet S03.4. Proceed to process the next header in the packet
S04. } S04. }
]]></artwork></figure> </sourcecode>
<t>One of the applications of the USP flavor is when a packet with an SRH is de
<t>One of the applications of the USP flavor is when a packe stined to an application on hosts with smartNICs ("Smart Network Interface Cards
t with an SRH is destined to an application on hosts with smartNICs implementing ") implementing SRv6. The USP flavor is used to remove the consumed SRH from the
SRv6. The USP flavor is used to remove the consumed SRH from the extension head extension header chain before sending the packet to the host.</t>
er chain before sending the packet to the host.</t> </section>
</section> <section numbered="true" toc="default">
<name>USD: Ultimate Segment Decapsulation</name>
<t>The Upper-Layer header processing of the End, End.X, and End.T beha
viors are modified as follows:</t>
<section title="USD: Ultimate Segment Decapsulation"> <t>End:</t>
<t>The Upper-layer header processing of the End, End.X and E <sourcecode type="pseudocode">
nd.T behaviors are modified as follows:</t> S01. If (Upper-Layer header type == 41(IPv6) ) {
<figure><artwork><![CDATA[ S02. Remove the outer IPv6 header with all its extension headers
End: S03. Submit the packet to the egress IPv6 FIB lookup for
S01. If (Upper-layer Header type == 41(IPv6) ) {
S02. Remove the outer IPv6 Header with all its extension headers
S03. Submit the packet to the egress IPv6 FIB lookup and
transmission to the new destination transmission to the new destination
S04. } Else if (Upper-layer Header type == 4(IPv4) ) { S04. } Else if (Upper-Layer header type == 4(IPv4) ) {
S05. Remove the outer IPv6 Header with all its extension headers S05. Remove the outer IPv6 header with all its extension headers
S06. Submit the packet to the egress IPv4 FIB lookup and S06. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination transmission to the new destination
S07. Else { S07. Else {
S08. Process as per Section 4.1.1 S08. Process as per Section 4.1.1
S09. } S09. }
]]></artwork></figure> </sourcecode>
<figure><artwork><![CDATA[ <t>End.T:</t>
End.T: <sourcecode type="pseudocode">
S01. If (Upper-layer Header type == 41(IPv6) ) { S01. If (Upper-Layer header type == 41(IPv6) ) {
S02. Remove the outer IPv6 Header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Set the packet's associated FIB table to T S03. Set the packet's associated FIB table to T
S04. Submit the packet to the egress IPv6 FIB lookup and S04. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination transmission to the new destination
S05. } Else if (Upper-layer Header type == 4(IPv4) ) { S05. } Else if (Upper-Layer header type == 4(IPv4) ) {
S06. Remove the outer IPv6 Header with all its extension headers S06. Remove the outer IPv6 header with all its extension headers
S07. Set the packet's associated FIB table to T S07. Set the packet's associated FIB table to T
S08. Submit the packet to the egress IPv4 FIB lookup and S08. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination transmission to the new destination
S09. Else { S09. Else {
S10. Process as per Section 4.1.1 S10. Process as per Section 4.1.1
S11. } S11. }
]]></artwork></figure> </sourcecode>
<figure><artwork><![CDATA[ <t>End.X:</t>
End.X: <sourcecode type="pseudocode">
S01. If (Upper-layer Header type == 41(IPv6) || S01. If (Upper-Layer header type == 41(IPv6) ||
Upper-layer Header type == 4(IPv4) ) { Upper-Layer header type == 4(IPv4) ) {
S02. Remove the outer IPv6 Header with all its extension headers S02. Remove the outer IPv6 header with all its extension headers
S03. Forward the exposed IP packet to the L3 adjacency J S03. Forward the exposed IP packet to the L3 adjacency J
S04. } Else { S04. } Else {
S05. Process as per Section 4.1.1 S05. Process as per Section 4.1.1
S06. } S06. }
]]></artwork></figure> </sourcecode>
<t>One of the applications of the USD flavor is the case of <t>One of the applications of the USD flavor is the case of a
TI-LFA in P routers with encapsulation. The USD flavor allows the last Segment E Topology Independent Loop-Free Alternate (TI-LFA) in P routers with
ndpoint Node in the repair path list to decapsulate the IPv6 header added at the encapsulation. The USD flavor allows the last SR Segment Endpoint Node
TI-LFA Point of Local Repair and forward the inner packet.</t> in the repair path list to decapsulate the IPv6 header added at the
</section> TI-LFA Point of Local Repair and forward the inner packet.</t>
</section>
</section> </section>
</section>
</section>
<section numbered="true" toc="default">
<name>SR Policy Headend Behaviors</name>
<t>This section describes a set of SRv6 Policy Headend <xref target="RFC84
02" format="default"/> behaviors.</t>
<section title="SR Policy Headend Behaviors"> <table anchor="headend">
<t>This section describes a set of SR Policy Headend <xref target="R <name>SR Policy Headend Behaviors</name>
FC8402" /> behaviors.</t>
<figure>
<artwork><![CDATA[
H.Encaps SR Headend Behavior with Encapsulation in an SR Policy
H.Encaps.Red H.Encaps with Reduced Encapsulation
H.Encaps.L2 H.Encaps Applied to Received L2 Frames
H.Encaps.L2.Red H.Encaps.Red Applied to Received L2 Frames
]]></artwork>
</figure>
<t>This list is not exhaustive and future documents may define addit
ional behaviors.</t>
<?rfc needLines="10" ?> <tbody>
<section title="H.Encaps: SR Headend with Encapsulation in an SRv6 P <tr>
olicy"> <td>H.Encaps
<t>Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, </td>
B1; SL=1). B2 is neither a local address nor SID of N.</t> <td>SR Headend with Encapsulation in an SR Policy
<t>Node N is configured with an IPv6 Address T (e.g. assigned to </td>
its loopback).</t> </tr>
<t>N steers the transit packets P1 and P2 into an SR Policy with <tr>
a Source Address T and a Segment list &lt;S1, S2, S3&gt;.</t> <td>H.Encaps.Red
<t>The H.Encaps encapsulation behavior is defined as follows:</t </td>
> <td>H.Encaps with Reduced Encapsulation
<figure><artwork><![CDATA[ </td>
</tr>
<tr>
<td>H.Encaps.L2
</td>
<td>H.Encaps Applied to Received L2 Frames
</td>
</tr>
<tr>
<td>H.Encaps.L2.Red
</td>
<td>H.Encaps.Red Applied to Received L2 Frames
</td>
</tr>
</tbody>
</table>
<t>This list is not exhaustive, and future documents may define additional
behaviors.</t>
<section numbered="true" toc="default">
<name>H.Encaps: SR Headend with Encapsulation in an SR Policy</name>
<t>Node N receives two packets P1=(A, B2) and P2=(A,B2)(B3, B2, B1;
SL=1). B2 is neither a local address nor SID of N.</t>
<t>Node N is configured with an IPv6 address T (e.g., assigned to its
loopback).</t> <t>N steers the transit packets P1 and P2 into an SRv6
Policy with a Source Address T and a segment list &lt;S1, S2,
S3&gt;.</t>
<t>The H.Encaps encapsulation behavior is defined as follows:</t>
<sourcecode type="pseudocode">
S01. Push an IPv6 header with its own SRH S01. Push an IPv6 header with its own SRH
S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID S02. Set outer IPv6 SA = T and outer IPv6 DA to the first SID
in the segment list in the segment list
S03. Set outer Payload Length, Traffic Class, Hop Limit and S03. Set outer Payload Length, Traffic Class, Hop Limit, and
Flow Label fields Flow Label fields
S04. Set the outer Next-Header value S04. Set the outer Next Header value
S05. Decrement inner IPv6 Hop Limit or IPv4 TTL S05. Decrement inner IPv6 Hop Limit or IPv4 TTL
S06. Submit the packet to the IPv6 module for transmission to S1 S06. Submit the packet to the IPv6 module for transmission to S1
]]></artwork></figure> </sourcecode>
<t>Note:<vspace blankLines="0" />S03: As described in <xref targ <aside>
et="RFC2473" /> and <xref target="RFC6437"/>. <vspace blankLines="1" /></t> <t>Note:</t>
<t>
S03: As described in <xref target="RFC2473" format="default"/> and <xref
target="RFC6437" format="default"/>. </t>
</aside>
<t>After the H.Encaps behavior, P1' and P2' respectively look like:
</t>
<ul spacing="normal"><li>(T, S1) (S3, S2, S1; SL=2) (A, B2)</li>
<li>(T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1)</li>
</ul>
<t>The received packet is encapsulated unmodified (with the exception of
the IPv4 TTL or IPv6 Hop Limit that is decremented as described in <xref target
="RFC2473" format="default"/>).</t>
<t>The H.Encaps behavior is valid for any kind of L3 traffic. This behav
ior is commonly used for L3VPN with IPv4 and IPv6 deployments. It may be also us
ed for TI-LFA <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa" format="defau
lt"/> at the Point of Local Repair.</t>
<t>The push of the SRH <bcp14>MAY</bcp14> be omitted when the SRv6
Policy only contains one segment and there is no need to use any flag,
tag, or TLV.</t>
</section>
<section numbered="true" toc="default">
<name>H.Encaps.Red: H.Encaps with Reduced Encapsulation</name>
<t>After the H.Encaps behavior, P1' and P2' respectively look li <t>The H.Encaps.Red behavior is an optimization of the H.Encaps behavior
ke: .</t>
<list style="format - "> <t>H.Encaps.Red reduces the length of the SRH by excluding the first
<t>(T, S1) (S3, S2, S1; SL=2) (A, B2)</t> SID in the SRH of the pushed IPv6 header. The first SID is only placed
<t>(T, S1) (S3, S2, S1; SL=2) (A, B2) (B3, B2, B1; SL=1) in the Destination Address field of the pushed IPv6 header.</t>
</t> <t>After the H.Encaps.Red behavior, P1' and P2' respectively look like:
</list></t> </t>
<t>The received packet is encapsulated unmodified (with the exce <ul spacing="normal"><li>(T, S1) (S3, S2; SL=2) (A, B2)</li>
ption of the IPv4 TTL or IPv6 Hop Limit that is decremented as described in <xre <li>(T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)</li>
f target="RFC2473"/>).</t> </ul>
<t>The H.Encaps behavior is valid for any kind of Layer-3 traffi <t>The push of the SRH <bcp14>MAY</bcp14> be omitted when the SRv6 Polic
c. This behavior is commonly used for L3VPN with IPv4 and IPv6 deployments. It m y only contains one segment and there is no need to use any flag, tag, or TLV.</
ay be also used for TI-LFA <xref target="I-D.ietf-rtgwg-segment-routing-ti-lfa"/ t>
> at the point of local repair.</t> </section>
<t>The push of the SRH MAY be omitted when the SRv6 Policy only <section numbered="true" toc="default">
contains one segment and there is no need to use any flag, tag or TLV.</t> <name>H.Encaps.L2: H.Encaps Applied to Received L2 Frames</name>
</section> <t>The H.Encaps.L2 behavior encapsulates a received Ethernet <xref targe
t="IEEE.802.3_2018" format="default"/> frame and its attached VLAN header, if pr
esent, in an IPv6 packet with an SRH. The Ethernet frame becomes the payload of
the new IPv6 packet.</t>
<t>The Next Header field of the SRH <bcp14>MUST</bcp14> be set to 143.</
t>
<t>The push of the SRH <bcp14>MAY</bcp14> be omitted when the SRv6
Policy only contains one segment and there is no need to use any flag,
tag, or TLV.</t>
<t>The encapsulating node <bcp14>MUST</bcp14> remove the preamble (if
any) and frame check sequence (FCS) from the Ethernet frame upon
encapsulation, and the decapsulating node <bcp14>MUST</bcp14>
regenerate, as required, the preamble and FCS before forwarding the
Ethernet frame.</t>
</section>
<section numbered="true" toc="default">
<name>H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 Frames</name>
<t>The H.Encaps.L2.Red behavior is an optimization of the H.Encaps.L2 be
havior.</t>
<t>H.Encaps.L2.Red reduces the length of the SRH by excluding the first
SID in the SRH of the pushed IPv6 header. The first SID is only placed in the De
stination Address field of the pushed IPv6 header.</t>
<?rfc needLines="10" ?> <t>The push of the SRH <bcp14>MAY</bcp14> be omitted when the SRv6 Polic
<section title="H.Encaps.Red: H.Encaps with Reduced Encapsulation"> y only contains one segment and there is no need to use any flag, tag, or TLV.</
<t>The H.Encaps.Red behavior is an optimization of the H.Encaps t>
behavior.</t> </section>
<t>H.Encaps.Red reduces the length of the SRH by excluding the f </section>
irst SID in the SRH of the pushed IPv6 header. The first SID is only placed in t <section numbered="true" toc="default">
he Destination Address field of the pushed IPv6 header.</t> <name>Counters</name>
<t>After the H.Encaps.Red behavior, P1' and P2' respectively loo <t>A node supporting this document <bcp14>SHOULD</bcp14> implement a pair
k like: of traffic counters (one for packets and one for bytes) per local SID entry, for
<list style="format - "> traffic that matched that SID and was processed successfully (i.e., packets tha
<t>(T, S1) (S3, S2; SL=2) (A, B2)</t> t generate ICMP Error Messages or are dropped are not counted). The retrieval of
<t>(T, S1) (S3, S2; SL=2) (A, B2) (B3, B2, B1; SL=1)</t> these counters from MIB, NETCONF/YANG, or any other data structure is outside t
</list></t> he scope of this document.</t>
<t>The push of the SRH MAY be omitted when the SRv6 Policy only </section>
contains one segment and there is no need to use any flag, tag or TLV.</t> <section anchor="OpsFlowLabel" numbered="true" toc="default">
</section> <name>Flow-Based Hash Computation</name>
<?rfc needLines="10" ?> <t>When a flow-based selection within a set needs to be performed, the
<section title="H.Encaps.L2: H.Encaps Applied to Received L2 Frames" IPv6 Source Address, the IPv6 Destination Address, and the IPv6 Flow
> Label of the outer IPv6 header <bcp14>MUST</bcp14> be included in the
<t>The H.Encaps.L2 behavior encapsulates a received Ethernet <xr flow-based hash.</t>
ef target="IEEE.802.3_2018"/> frame and its attached VLAN header, if present, in <t>This may occur in any of the following scenarios:</t>
an IPv6 packet with an SRH. The Ethernet frame becomes the payload of the new I <ul>
Pv6 packet.</t> <li>
<t>The Next Header field of the SRH MUST be set to 143.</t> <t>A FIB lookup is performed and multiple ECMP paths
<t>The push of the SRH MAY be omitted when the SRv6 Policy only exist to the updated destination address.</t>
contains one segment and there is no need to use any flag, tag or TLV.</t> </li>
<t>The encapsulating node MUST remove the preamble (if any) and <li> <t>End.X, End.DX4, or End.DX6 is bound to an array of adjacencies.</t>
frame check sequence (FCS) from the Ethernet frame upon encapsulation and the de </li>
capsulating node MUST regenerate, as required, the preamble and FCS before forwa <li> <t>The packet is steered in an SR Policy whose selected
rding Ethernet frame.</t> path has multiple SID lists.</t></li>
</section> </ul>
<?rfc needLines="10" ?> <t>Additionally, any transit router in an SRv6 domain includes the outer
<section title="H.Encaps.L2.Red: H.Encaps.Red Applied to Received L2 flow label in its ECMP flow-based hash <xref target="RFC6437"
frames"> format="default"/>.</t>
<t>The H.Encaps.L2.Red behavior is an optimization of the H.Enca
ps.L2 behavior.</t>
<t>H.Encaps.L2.Red reduces the length of the SRH by excluding th
e first SID in the SRH of the pushed IPv6 header. The first SID is only places i
n the Destination Address field of the pushed IPv6 header.</t>
<t>The push of the SRH MAY be omitted when the SRv6 Policy only
contains one segment and there is no need to use any flag, tag or TLV.</t>
</section>
</section>
<?rfc needLines="10" ?> </section>
<section title="Counters"> <section anchor="cp" numbered="true" toc="default">
<t>A node supporting this document SHOULD implement a pair of traffi <name>Control Plane</name>
c counters (one for packets and one for bytes) per local SID entry, for traffic <t>In an SDN environment, one expects the controller to explicitly
that matched that SID and was processed successfully (i.e. packets which generat provision the SIDs and/or discover them as part of a service discovery
e ICMP Error Messages or are dropped are not counted). The retrieval of these co function. Applications residing on top of the controller could then
unters from MIB, NETCONF/YANG or any other data structure is outside the scope o discover the required SIDs and combine them to form a distributed
f this document.</t> network program.</t>
</section> <t>The concept of "SRv6 Network Programming" refers to the capability of
an application to encode any complex program as a set of individual
functions distributed through the network. Some functions relate to
underlay SLA, others to overlay/tenant, and others to complex
applications residing in VMs and containers.</t>
<t>While not necessary for an SDN control plane, the remainder of this
section provides a high-level illustrative overview of how control-plane
protocols may be involved with SRv6. Their specification is outside the
scope of this document.</t>
<section anchor="igp" numbered="true" toc="default">
<name>IGP</name>
<t>The End, End.T, and End.X SIDs express topological behaviors and
hence are expected to be signaled in the IGP together with the flavors
PSP, USP, and USD. The IGP should also advertise the Maximum SID
Depth (MSD) capability of the node for each type of SRv6 operation --
in particular, the SR source (e.g., H.Encaps), intermediate endpoint
(e.g., End and End.X), and final endpoint (e.g., End.DX4 and End.DT6)
behaviors. These capabilities are factored in by an SR source node (or
a controller) during the SR Policy computation.</t>
<t>The presence of SIDs in the IGP does not imply any routing semantics
to the addresses represented by these SIDs. The routing reachability to an IPv6
address is solely governed by the non-SID-related IGP prefix reachability inform
ation that includes locators. Routing is neither governed nor influenced in any
way by a SID advertisement in the IGP.</t>
<t>These SIDs provide important topological behaviors for the IGP to
build Fast Reroute (FRR) solutions based on TI-LFA <xref
target="I-D.ietf-rtgwg-segment-routing-ti-lfa" format="default"/> and
for TE processes relying on an IGP topology database to build SR
Policies.</t>
</section>
<section numbered="true" toc="default">
<name>BGP-LS</name>
<t>BGP-LS provides the functionality for topology discovery that
includes the SRv6 capabilities of the nodes, their locators, and
locally instantiated SIDs. This enables controllers or applications to
build an inter-domain topology that can be used for computation of SR
Policies using the SRv6 SIDs.</t>
</section>
<section numbered="true" toc="default">
<name>BGP IP/VPN/EVPN</name>
<t>The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2,
End.DX2V, End.DT2U, and End.DT2M SIDs can be signaled in BGP.</t>
<t>In some scenarios, an egress PE advertising a VPN route might wish
to abstract the specific behavior bound to the SID from the ingress PE
and other routers in the network. In such case, the SID may be
advertised using the Opaque SRv6 Endpoint Behavior codepoint defined
in <xref target="endpoint_cp_types" format="default"/>. The details of
such control-plane signaling mechanisms are out of the scope of this
document.</t>
</section>
<section numbered="true" toc="default">
<name>Summary</name>
<t>The following table summarizes which SID behaviors
may be signaled in which control-plane protocol.</t>
<?rfc needLines="5" ?> <table anchor="localsid_signaling" align="center">
<section title="Flow-based Hash Computation" anchor="OpsFlowLabel" > <name>SRv6 Locally Instantiated SIDs Signaling</name>
<t>When a flow-based selection within a set needs to be performed, t <thead>
he IPv6 Source Address, the IPv6 Destination Address and the IPv6 Flow Label of <tr>
the outer IPv6 header MUST be included in the flow-based hash.</t> <th align="left"/>
<t>This occurs when a FIB lookup is performed and multiple ECMP path <th align="center">IGP</th>
s exist to the updated destination address.</t> <th align="center">BGP-LS</th>
<t>This occurs when End.X, End.DX4, or End.DX6 are bound to an array <th align="center">BGP IP/VPN/EVPN</th>
of adjacencies.</t> </tr>
<t>This occurs when the packet is steered in an SR policy whose sele </thead>
cted path has multiple SID lists.</t> <tbody>
<t>Additionally, any transit router in an SRv6 domain includes the o <tr>
uter flow label in its ECMP flow-based hash <xref target="RFC6437" />.</t> <td align="left">End (PSP, USP, USD)</td>
</section> <td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">End.X (PSP, USP, USD)</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">End.T (PSP, USP, USD)</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">End.DX6</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DX4</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DT6</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DT4</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DT46</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DX2</td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DX2V</td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DT2U</td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.DT2M</td>
<td align="center"/>
<td align="center">X</td>
<td align="center">X</td>
</tr>
<tr>
<td align="left">End.B6.Encaps</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">End.B6.Encaps.Red</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">End.B6.BM</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
</tbody>
</table>
<t>The following table summarizes which SR Policy Headend capabilities
may be signaled in which control-plane protocol.</t>
<table anchor="transit_signaling" align="center">
<name>SRv6 Policy Headend Behaviors Signaling</name>
<thead>
<tr>
<th align="left"/>
<th align="center">IGP</th>
<th align="center">BGP-LS</th>
<th align="center">BGP IP/VPN/EVPN</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">H.Encaps</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">H.Encaps.Red</td>
<td align="center">X</td>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">H.Encaps.L2</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
<tr>
<td align="left">H.Encaps.L2.Red</td>
<td align="center"/>
<td align="center">X</td>
<td align="center"/>
</tr>
</tbody>
</table>
<t>The previous table describes generic capabilities. It does not
describe specific instantiated SR Policies.</t>
<t>For example, a BGP-LS advertisement of H.Encaps behavior would
describe the capability of node N to perform H.Encaps
behavior. Specifically, it would describe how many SIDs could be
pushed by N without significant performance degradation.</t>
<t/>
<t>As a reminder, an SR Policy is always assigned a Binding SID
<xref target="RFC8402" format="default"/>. Binding SIDs are also adverti
sed
in BGP-LS as shown in <xref target="localsid_signaling"
format="default"/>. Hence, <xref target="transit_signaling"
format="default"/> only focuses on the generic capabilities related to
H.Encaps.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<?rfc needLines="8" ?> <t>The security considerations for Segment Routing are discussed in
<section title="Control Plane" anchor="cp"> <xref target="RFC8402" format="default"/>. <xref target="RFC8754"
<t>In an SDN environment, one expects the controller to explicitly p sectionFormat="of" section="5" format="default"/> describes the SR
rovision the SIDs and/or discover them as part of a service discovery function. Deployment Model and the requirements for securing the SR Domain. The
Applications residing on top of the controller could then discover the required security considerations of <xref target="RFC8754"/> also cover topics
SIDs and combine them to form a distributed network program.</t> such as attack vectors and their mitigation mechanisms that also apply
<t>The concept of &quot;SRv6 network programming&quot; refers to the the behaviors introduced in this document. Together, they describe the
capability for an application to encode any complex program as a set of individ required security mechanisms that allow establishment of an SR domain of
ual functions distributed through the network. Some functions relate to underlay trust. Having such a well-defined trust boundary is necessary in order
SLA, others to overlay/tenant, others to complex applications residing in VM an to operate SRv6-based services for internal traffic while preventing any
d containers.</t> external traffic from accessing or exploiting the SRv6-based services.
<t>While not necessary for an SDN control plane, the remainder of th Care and rigor in IPv6 address allocation for use for SRv6 SID
is section provides a high-level illustrative overview of how control-plane prot allocations and network infrastructure addresses, as distinct from IPv6
ocols may be involved with SRv6. Their specification is outside the scope of thi addresses allocated for end users and systems (as illustrated in <xref
s document.</t> target="RFC8754" sectionFormat="of" section="5.1" format="default"/>),
can provide the clear distinction between internal and external address
space that is required to maintain the integrity and security of the
SRv6 Domain. Additionally, <xref target="RFC8754" format="default"/>
defines a Hashed Message Authentication Code (HMAC) TLV permitting SR
Segment Endpoint Nodes in the SR domain to verify that the SRH applied to
a
packet was selected by an authorized party and to ensure that the
segment list is not modified after generation, regardless of the number
of segments in the segment list. When enabled by local configuration,
HMAC processing occurs at the beginning of SRH processing as defined in
<xref target="RFC8754" sectionFormat="of" section="2.1.2.1"
format="default"/>.</t>
<section title="IGP" anchor="igp"> <t>This document introduces SRv6 Endpoint and SR Policy Headend
<t>The End, End.T and End.X SIDs express topological behaviors a behaviors for implementation on SRv6-capable nodes in the network. The
nd hence are expected to be signaled in the IGP together with the flavors PSP, U definition of the SR Policy Headend should be consistent with the
SP and USD. The IGP should also advertise the maximum SRv6 SID depth (MSD) capab specific behavior used and any local configuration (as specified in
ility of the node for each type of SRv6 operation - in particular, the SR source <xref target="upper"/>). As such, this document does not introduce any
(e.g. H.Encaps), intermediate endpoint (e.g. End, End.X) and final endpoint (e. new security considerations.</t>
g. End.DX4, End.DT6) behaviors. These capabilities are factored in by an SR Sour <t>The SID behaviors specified in this document have the same HMAC TLV
ce Node (or a controller) during the SR Policy computation.</t> handling and mutability properties with regard to the Flags, Tag, and Segm
<t>The presence of SIDs in the IGP does not imply any routing se ent List
mantics to the addresses represented by these SIDs. The routing reachability to field as the SID behavior specified in <xref target="RFC8754"
an IPv6 address is solely governed by the non-SID-related IGP prefix reachabilit format="default"/>.</t>
y information that includes locators. Routing is neither governed nor influenced
in any way by a SID advertisement in the IGP.</t>
<t>These SIDs provide important topological behaviors for the IG
P to build FRR solutions based on TI-LFA <xref target="I-D.ietf-rtgwg-segment-ro
uting-ti-lfa"/> and for TE processes relying on IGP topology database to build S
R policies.</t>
</section>
<section title="BGP-LS"> </section>
<t>BGP-LS provides the functionality for topology discovery that <section numbered="true" toc="default">
includes the SRv6 capabilities of the nodes, their locators and locally instant <name>IANA Considerations</name>
iated SIDs. This enables controllers or applications to build an inter-domain to
pology that can be used for computation of SR Policies using the SRv6 SIDs.</t>
</section>
<section title="BGP IP/VPN/EVPN"> <section anchor="ianaethernet" numbered="true" toc="default">
<t>The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, En <name>Ethernet Next Header Type</name>
d.DX2V, End.DT2U and End.DT2M SIDs can be signaled in BGP.</t> <t>IANA has allocated "Ethernet" (value 143) in the "Assigned
<t>In some scenarios an egress PE advertising a VPN route might Internet Protocol Numbers" registry (see <eref brackets="angle"
wish to abstract the specific behavior bound to the SID from the ingress PE and target="https://www.iana.org/assignments/protocol-numbers/"/>).
other routers in the network. In such case, the SID may be advertised using the Value 143 in the Next Header field of an IPv6 header or any extension
Opaque SRv6 Endpoint Behavior codepoint defined in <xref target="endpoint_cp_typ header indicates that the payload is an Ethernet frame <xref
es"/>. The details of such control plane signaling mechanisms are out of the sco target="IEEE.802.3_2018" format="default"/>.</t>
pe of this document.</t>
</section>
<section title="Summary"> </section>
<t>The following table summarizes behaviors for SIDs that can be <section anchor="iana_registry" numbered="true" toc="default">
signaled in which each respective control plane protocol.</t> <name>SRv6 Endpoint Behaviors Registry</name>
<t>IANA has created a new top-level registry
called "Segment Routing" (see <eref brackets="angle"
target="https://www.iana.org/assignments/segment-routing/"/>). This
registry serves as a top-level registry for all
Segment Routing subregistries.</t>
<t>Additionally, IANA has created a new subregistry called "SRv6 Endpoin
t Behaviors"
under the top-level "Segment Routing" registry. This
subregistry maintains 16-bit identifiers for the SRv6 Endpoint
behaviors. This registry is established to provide consistency for
control-plane protocols that need to refer to these behaviors. These
values are not encoded in the function bits within a SID.</t>
<texttable anchor="localsid_signaling" title="SRv6 locally insta <section anchor="iana_policy" numbered="true" toc="default">
ntiated SIDs signaling"> <name>Registration Procedures</name>
<ttcol align="left"></ttcol>
<ttcol align="center">IGP</ttcol>
<ttcol align="center">BGP-LS</ttcol>
<ttcol align="center">BGP IP/VPN/EVPN</ttcol>
<c>End (PSP, USP, USD)</c> <t>The range of the registry is 0-65535 (0x0000-0xFFFF). The table below
<c>X</c> contains the allocation ranges and
<c>X</c> registration policies <xref
<c></c> target="RFC8126" format="default"/> for each:</t>
<c>End.X (PSP, USP, USD)</c> <table anchor="endpoint_cp_codepoint_ranges" align="center">
<c>X</c> <name>Registration Procedures</name>
<c>X</c> <thead>
<c></c> <tr>
<c>End.T (PSP, USP, USD)</c> <th align="left">Range</th>
<c>X</c> <th align="center">Range (Hex)</th>
<c>X</c> <th align="center">Registration Procedures</th>
<c></c> <th align="center">Note</th>
<c>End.DX6</c> </tr>
<c>X</c> </thead>
<c>X</c> <tbody>
<c>X</c> <tr>
<c>End.DX4</c> <td align="left">0</td>
<c>X</c> <td align="center">0x0000</td>
<c>X</c> <td align="center">Reserved</td>
<c>X</c> <td align="center">Not to be allocated</td>
<c>End.DT6</c> </tr>
<c>X</c> <tr>
<c>X</c> <td align="left">1-32767</td>
<c>X</c> <td align="center">0x0001-0x7FFF</td>
<c>End.DT4</c> <td align="center">First Come First Served</td>
<c>X</c> <td align="center"/>
<c>X</c> </tr>
<c>X</c> <tr>
<c>End.DT46</c> <td align="left">32768-34815</td>
<c>X</c> <td align="center">0x8000-0x87FF</td>
<c>X</c> <td align="center">Private Use</td>
<c>X</c> <td align="center"/>
<c>End.DX2</c> </tr>
<c></c> <tr>
<c>X</c> <td align="left">34816-65534</td>
<c>X</c> <td align="center">0x8800-0xFFFE</td>
<c>End.DX2V</c> <td align="center">Reserved</td>
<c></c> <td align="center"/>
<c>X</c> </tr>
<c>X</c> <tr>
<c>End.DT2U</c> <td align="left">65535</td>
<c></c> <td align="center">0xFFFF</td>
<c>X</c> <td align="center">Reserved</td>
<c>X</c> <td align="center">Opaque</td>
<c>End.DT2M</c> </tr>
<c></c> </tbody>
<c>X</c> </table>
<c>X</c> </section>
<c>End.B6.Encaps</c> <section numbered="true" toc="default">
<c></c> <name>Initial Registrations</name>
<c>X</c> <t>The initial registrations for the subregistry are as follows:</t>
<c></c> <table anchor="endpoint_cp_types" align="center">
<c>End.B6.Encaps.Red</c> <name>Initial Registrations</name>
<c></c> <thead>
<c>X</c> <tr>
<c></c> <th align="left">Value</th>
<c>End.B6.BM</c> <th align="center">Hex</th>
<c></c> <th align="center">Endpoint Behavior</th>
<c>X</c> <th align="center">Reference</th>
<c></c> </tr>
</texttable> </thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="center">0x0000</td>
<td align="center">Reserved</td>
<td align="center"></td>
</tr>
<tr>
<td align="left">1</td>
<td align="center">0x0001</td>
<td align="center">End</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">2</td>
<td align="center">0x0002</td>
<td align="center">End with PSP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">3</td>
<td align="center">0x0003</td>
<td align="center">End with USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">4</td>
<td align="center">0x0004</td>
<td align="center">End with PSP &amp; USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">5</td>
<td align="center">0x0005</td>
<td align="center">End.X</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">6</td>
<td align="center">0x0006</td>
<td align="center">End.X with PSP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">7</td>
<td align="center">0x0007</td>
<td align="center">End.X with USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">8</td>
<td align="center">0x0008</td>
<td align="center">End.X with PSP &amp; USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">9</td>
<td align="center">0x0009</td>
<td align="center">End.T</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">10</td>
<td align="center">0x000A</td>
<td align="center">End.T with PSP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">11</td>
<td align="center">0x000B</td>
<td align="center">End.T with USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">12</td>
<td align="center">0x000C</td>
<td align="center">End.T with PSP &amp; USP</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">13</td>
<td align="center">0x000D</td>
<td align="center">Unassigned</td>
<td align="center"></td>
</tr>
<tr>
<td align="left">14</td>
<td align="center">0x000E</td>
<td align="center">End.B6.Encaps</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">15</td>
<td align="center">0x000F</td>
<td align="center">End.BM</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">16</td>
<td align="center">0x0010</td>
<td align="center">End.DX6</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">17</td>
<td align="center">0x0011</td>
<td align="center">End.DX4</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">18</td>
<td align="center">0x0012</td>
<td align="center">End.DT6</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">19</td>
<td align="center">0x0013</td>
<td align="center">End.DT4</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">20</td>
<td align="center">0x0014</td>
<td align="center">End.DT46</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">21</td>
<td align="center">0x0015</td>
<td align="center">End.DX2</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">22</td>
<td align="center">0x0016</td>
<td align="center">End.DX2V</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">23</td>
<td align="center">0x0017</td>
<td align="center">End.DT2U</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">24</td>
<td align="center">0x0018</td>
<td align="center">End.DT2M</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">25</td>
<td align="center">0x0019</td>
<td align="center">Reserved</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">26</td>
<td align="center">0x001A</td>
<td align="center">Unassigned</td>
<td align="center"></td>
</tr>
<tr>
<td align="left">27</td>
<td align="center">0x001B</td>
<td align="center">End.B6.Encaps.Red</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">28</td>
<td align="center">0x001C</td>
<td align="center">End with USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">29</td>
<td align="center">0x001D</td>
<td align="center">End with PSP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">30</td>
<td align="center">0x001E</td>
<td align="center">End with USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">31</td>
<td align="center">0x001F</td>
<td align="center">End with PSP, USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">32</td>
<td align="center">0x0020</td>
<td align="center">End.X with USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">33</td>
<td align="center">0x0021</td>
<td align="center">End.X with PSP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">34</td>
<td align="center">0x0022</td>
<td align="center">End.X with USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">35</td>
<td align="center">0x0023</td>
<td align="center">End.X with PSP, USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">36</td>
<td align="center">0x0024</td>
<td align="center">End.T with USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">37</td>
<td align="center">0x0025</td>
<td align="center">End.T with PSP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">38</td>
<td align="center">0x0026</td>
<td align="center">End.T with USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">39</td>
<td align="center">0x0027</td>
<td align="center">End.T with PSP, USP &amp; USD</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">40-32766</td>
<td align="center">0x0028-0x7FFE</td>
<td align="center">Unassigned</td>
<td align="center"/>
</tr>
<tr>
<td align="left">32767</td>
<td align="center">0x7FFF</td>
<td align="center">The SID defined in RFC 8754</td>
<td align="center">RFC 8986, RFC 8754</td>
</tr>
<tr>
<td align="left">32768-34815</td>
<td align="center">0x8000-0x87FF</td>
<td align="center">Reserved for Private Use</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">34816-65534</td>
<td align="center">0x8800-0xFFFE</td>
<td align="center">Reserved</td>
<td align="center">RFC 8986</td>
</tr>
<tr>
<td align="left">65535</td>
<td align="center">0xFFFF</td>
<td align="center">Opaque</td>
<td align="center">RFC 8986</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<t>The following table summarizes which SR Policy Headend capabi </middle>
lities are signaled in which signaling protocol.</t> <back>
<texttable anchor="transit_signaling" title="SRv6 Policy Headend <displayreference target="I-D.filsfils-spring-srv6-net-pgm-illustration" to="SRV
behaviors signaling"> 6-NET-PGM-ILLUST"/>
<ttcol align="left"></ttcol> <displayreference target="I-D.ietf-rtgwg-segment-routing-ti-lfa" to="SR-TI-LFA"/
<ttcol align="center">IGP</ttcol> >
<ttcol align="center">BGP-LS</ttcol>
<ttcol align="center">BGP IP/VPN/EVPN</ttcol>
<c>H.Encaps</c> <references>
<c>X</c> <name>References</name>
<c>X</c> <references>
<c></c> <name>Normative References</name>
<c>H.Encaps.Red</c>
<c>X</c>
<c>X</c>
<c></c>
<c>H.Encaps.L2</c>
<c></c>
<c>X</c>
<c></c>
<c>H.Encaps.L2.Red</c>
<c></c>
<c>X</c>
<c></c>
</texttable>
<t>The previous table describes generic capabilities. It does no <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
t describe specific instantiated SR policies.</t> FC.2119.xml"/>
<t>For example, a BGP-LS advertisement of H.Encaps behavior woul <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
d describe the capability of node N to perform a H.Encaps behavior. Specifically FC.8174.xml"/>
, it would describe how many SIDs could be pushed by N without significant perfo <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
rmance degradation.</t> FC.8754.xml"/>
<t><vspace blankLines="1" /></t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>As a reminder, an SR policy is always assigned a Binding SID FC.2473.xml"/>
<xref target="RFC8402" />. BSIDs are also advertised in BGP-LS as shown in <xref <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
target="localsid_signaling" />. Hence, the <xref target="transit_signaling" /> FC.8200.xml"/>
only focuses on the generic capabilities related to H.Encaps.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</section> FC.8402.xml"/>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6437.xml"/>
<?rfc needLines="10" ?> <reference anchor="IEEE.802.3_2018" target="https://ieeexplore.ieee.org/
<section title="Security Considerations"> document/8457469">
<t>The security considerations for Segment Routing are discussed in <front>
<xref target="RFC8402"/>. <title>IEEE Standard for Ethernet</title>
Section 5 of <xref target="RFC8754"/> describes the SR Deployment Mo <author>
del and the requirements for securing the SR Domain. The security considerations <organization>IEEE</organization>
of [RFC8754] also cover topics such as attack vectors and their mitigation mech </author>
anisms that also apply the behaviors introduced in this document. <date day="31" month="August" year="2018"/>
Together, they describe the required security mechanisms that allow </front>
establishment of an SR domain of trust.
Having such a well-defined trust boundary is necessary in order to o
perate SRv6-based services for internal traffic while preventing any external tr
affic from accessing or exploiting the SRv6-based services.
Care and rigor in IPv6 address allocation for use for SRv6 SID alloc
ations and network infrastructure addresses, as distinct from IPv6 addresses all
ocated for end-users/systems (as illustrated in Section 5.1 of <xref target="RFC
8754"/>), can provide the clear distinction between internal and external addres
s space that is required to maintain the integrity and security of the SRv6 Doma
in.
Additionally, <xref target="RFC8754"/> defines an HMAC TLV permittin
g SR Endpoint Nodes in the SR domain to verify that the SRH applied to a packet
was selected by an authorized party and to ensure that the segment list is not m
odified after generation, regardless of the number of segments in the segment li
st. When enabled by local configuration, HMAC processing occurs at the beginning
of SRH processing as defined in <xref target="RFC8754"/> Section 2.1.2.1 .</t>
<t>This document introduces SRv6 Endpoint and SR Policy Headend beha <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/>
viors for implementation on SRv6 capable nodes in the network. The headend polic <refcontent>IEEE 802.3-2018</refcontent>
y definition should be consistent with the specific behavior used and any local </reference>
configuration (as specified in Section 4.1.1). As such, this document does not i
ntroduce any new security considerations.</t>
<t>The SID Behaviors specified in this document have the same HMAC T </references>
LV handling and mutability properties of the Flags, Tag, and Segment List field <references>
as the SID Behavior specified in <xref target="RFC8754"/>.</t> <name>Informative References</name>
</section> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<section title="IANA Considerations"> <reference anchor='I-D.filsfils-spring-srv6-net-pgm-illustration'>
<section title="Ethernet Next Header Type" anchor="ianaethernet"> <front>
<t>This document requests IANA to allocate, in the &quot;Protoco <title>Illustrations for SRv6 Network Programming</title>
l Numbers&quot; registry (https://www.iana.org/assignments/protocol-numbers/prot
ocol-numbers.xhtml), a new value for &quot;Ethernet&quot; with the following def
inition: The value 143 in the Next Header field of an IPv6 header or any extensi
on header indicates that the payload is an Ethernet frame <xref target="IEEE.802
.3_2018" />.</t>
<t>IANA has done a temporary allocation of Protocol Number 143.<
/t>
</section>
<section title="SRv6 Endpoint Behaviors Registry" anchor="iana_regis <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
try"> <organization />
<t>This document requests IANA to create a new top-level registr </author>
y called &quot;Segment Routing Parameters&quot;. This registry is being defined
to serve as a top-level registry for keeping all other Segment Routing sub-regis
tries.</t>
<t>Additionally, a new sub-registry &quot;SRv6 Endpoint Behavior
s&quot; is to be created under top-level &quot;Segment Routing Parameters&quot;
registry. This sub-registry maintains 16-bit identifiers for the SRv6 Endpoint b
ehaviors. This registry is established to provide consistency for control plane
protocols which need to refer to these behaviors. These values are not encoded i
n the function bits within a SID.</t>
<t>The range of the registry is 0-65535 (0x0000 - 0xFFFF) and ha
s the following registration rules and allocation policies:</t>
<texttable anchor="endpoint_cp_codepoint_ranges" title="SRv6 End <author initials='P' surname='Camarillo' fullname='Pablo Camarillo' role="editor
point Behaviors Registry"> ">
<ttcol align="left">Range</ttcol> <organization />
<ttcol align="center">Hex</ttcol> </author>
<ttcol align="center">Registration procedure</ttcol>
<ttcol align="center">Notes</ttcol>
<c>0</c> <author initials='Z' surname='Li' fullname='Zhenbin Li'>
<c>0x0000</c> <organization />
<c>Reserved</c> </author>
<c>Not to be allocated</c>
<c>1-32767</c> <author initials='S' surname='Matsushima' fullname='Satoru Matsushima'>
<c>0x0001-0x7FFF</c> <organization />
<c>First Come First Served <xref target="RFC8126" /></c> </author>
<c></c>
<c>32768-34815</c> <author initials='B' surname='Decraene' fullname='Bruno Decraene'>
<c>0x8000-0x87FF</c> <organization />
<c>Private Use <xref target="RFC8126" /></c> </author>
<c></c>
<c>34816-65534</c> <author initials='D' surname='Steinberg' fullname='Dirk Steinberg'>
<c>0x8800-0xFFFE</c> <organization />
<c>Reserved</c> </author>
<c></c>
<c>65535</c> <author initials='D' surname='Lebrun' fullname='David Lebrun'>
<c>0xFFFF</c> <organization />
<c>Reserved</c> </author>
<c>Opaque</c>
</texttable>
<section title="Initial Registrations"> <author initials='R' surname='Raszuk' fullname='Robert Raszuk'>
<t>The initial registrations for the sub-registry are as fol <organization />
lows:</t> </author>
<texttable anchor="endpoint_cp_types" title="IETF - SRv6 End
point Behaviors">
<ttcol align="left">Value</ttcol>
<ttcol align="center">Hex</ttcol>
<ttcol align="center">Endpoint behavior</ttcol>
<ttcol align="center">Reference</ttcol>
<c>0</c>
<c>0x0000</c>
<c>Reserved</c>
<c>Not to be allocated</c>
<c>1</c>
<c>0x0001</c>
<c>End</c>
<c>[This.ID]</c>
<c>2</c>
<c>0x0002</c>
<c>End with PSP</c>
<c>[This.ID]</c>
<c>3</c>
<c>0x0003</c>
<c>End with USP</c>
<c>[This.ID]</c>
<c>4</c>
<c>0x0004</c>
<c>End with PSP&amp;USP</c>
<c>[This.ID]</c>
<c>5</c>
<c>0x0005</c>
<c>End.X</c>
<c>[This.ID]</c>
<c>6</c>
<c>0x0006</c>
<c>End.X with PSP</c>
<c>[This.ID]</c>
<c>7</c>
<c>0x0007</c>
<c>End.X with USP</c>
<c>[This.ID]</c>
<c>8</c>
<c>0x0008</c>
<c>End.X with PSP&amp;USP</c>
<c>[This.ID]</c>
<c>9</c>
<c>0x0009</c>
<c>End.T</c>
<c>[This.ID]</c>
<c>10</c>
<c>0x000A</c>
<c>End.T with PSP</c>
<c>[This.ID]</c>
<c>11</c>
<c>0x000B</c>
<c>End.T with USP</c>
<c>[This.ID]</c>
<c>12</c>
<c>0x000C</c>
<c>End.T with PSP&amp;USP</c>
<c>[This.ID]</c>
<c>14</c>
<c>0x000E</c>
<c>End.B6.Encaps</c>
<c>[This.ID]</c>
<c>15</c>
<c>0x000F</c>
<c>End.BM</c>
<c>[This.ID]</c>
<c>16</c>
<c>0x0010</c>
<c>End.DX6</c>
<c>[This.ID]</c>
<c>17</c>
<c>0x0011</c>
<c>End.DX4</c>
<c>[This.ID]</c>
<c>18</c>
<c>0x0012</c>
<c>End.DT6</c>
<c>[This.ID]</c>
<c>19</c>
<c>0x0013</c>
<c>End.DT4</c>
<c>[This.ID]</c>
<c>20</c>
<c>0x0014</c>
<c>End.DT46</c>
<c>[This.ID]</c>
<c>21</c>
<c>0x0015</c>
<c>End.DX2</c>
<c>[This.ID]</c>
<c>22</c>
<c>0x0016</c>
<c>End.DX2V</c>
<c>[This.ID]</c>
<c>23</c>
<c>0x0017</c>
<c>End.DT2U</c>
<c>[This.ID]</c>
<c>24</c>
<c>0x0018</c>
<c>End.DT2M</c>
<c>[This.ID]</c>
<c>25</c>
<c>0x0019</c>
<c>Reserved</c>
<c>[This.ID]</c>
<c>27</c>
<c>0x001B</c>
<c>End.B6.Encaps.Red</c>
<c>[This.ID]</c>
<c>28</c>
<c>0x001C</c>
<c>End with USD</c>
<c>[This.ID]</c>
<c>29</c>
<c>0x001D</c>
<c>End with PSP&amp;USD</c>
<c>[This.ID]</c>
<c>30</c>
<c>0x001E</c>
<c>End with USP&amp;USD</c>
<c>[This.ID]</c>
<c>31</c>
<c>0x001F</c>
<c>End with PSP, USP &amp; USD</c>
<c>[This.ID]</c>
<c>32</c>
<c>0x0020</c>
<c>End.X with USD</c>
<c>[This.ID]</c>
<c>33</c>
<c>0x0021</c>
<c>End.X with PSP&amp;USD</c>
<c>[This.ID]</c>
<c>34</c>
<c>0x0022</c>
<c>End.X with USP&amp;USD</c>
<c>[This.ID]</c>
<c>35</c>
<c>0x0023</c>
<c>End.X with PSP, USP &amp; USD</c>
<c>[This.ID]</c>
<c>36</c>
<c>0x0024</c>
<c>End.T with USD</c>
<c>[This.ID]</c>
<c>37</c>
<c>0x0025</c>
<c>End.T with PSP&amp;USD</c>
<c>[This.ID]</c>
<c>38</c>
<c>0x0026</c>
<c>End.T with USP&amp;USD</c>
<c>[This.ID]</c>
<c>39</c>
<c>0x0027</c>
<c>End.T with PSP, USP &amp; USD</c>
<c>[This.ID]</c>
<c>40-32766</c>
<c></c>
<c>Unassigned</c>
<c></c>
<c>32767</c>
<c>0x7FFF</c>
<c>The SID defined in RFC8754</c>
<c>[This.ID] <xref target="RFC8754" /></c>
<c>32768-65534</c>
<c></c>
<c>Reserved</c>
<c></c>
<c>65535</c>
<c>0xFFFF</c>
<c>Opaque</c>
<c>[This.ID]</c>
</texttable>
</section>
</section>
</section>
<?rfc needLines="1" ?> <author initials='J' surname='Leddy' fullname='John Leddy'>
<section anchor="Acknowledgements" title="Acknowledgements"> <organization />
<t>The authors would like to acknowledge Stefano Previdi, Dave Barac </author>
h, Mark Townsley, Peter Psenak, Thierry Couture, Kris Michielsen, Paul Wells, Ro
bert Hanzl, Dan Ye, Gaurav Dawra, Faisal Iqbal, Jaganbabu Rajamanickam, David To
scano, Asif Islam, Jianda Liu, Yunpeng Zhang, Jiaoming Li, Narendra A.K, Mike Mc
Gourty, Bhupendra Yadav, Sherif Toulan, Satish Damodaran, John Bettink, Kishore
Nandyala Veera Venk, Jisu Bhattacharya, Saleem Hafeez and Brian Carpenter.</t>
</section>
<?rfc needLines="1" ?> <date month='September' day='25' year='2020' />
<section title="Contributors">
<t>Daniel Bernier<vspace blankLines="0" /> </front>
Bell Canada<vspace blankLines="0" />
Canada</t>
<t>Email: daniel.bernier@bell.ca<vspace blankLines="0" /></t>
<t>Dirk Steinberg<vspace blankLines="0" /> <seriesInfo name='Internet-Draft' value='draft-filsfils-spring-srv6-net-pgm-illu
Lapishills Consulting Limited<vspace blankLines="0" /> stration-03' />
Cyprus</t> <format type='TXT'
<t>Email: dirk@lapishills.com<vspace blankLines="0" /></t> target='http://www.ietf.org/internet-drafts/draft-filsfils-spring-srv6-n
et-pgm-illustration-03.txt' />
</reference>
<t>Robert Raszuk<vspace blankLines="0" /> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
Bloomberg LP<vspace blankLines="0" /> .ietf-rtgwg-segment-routing-ti-lfa.xml"/>
United States of America</t>
<t>Email: robert@raszuk.net<vspace blankLines="0" /></t>
<t>Bruno Decraene<vspace blankLines="0" /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
Orange<vspace blankLines="0" /> FC.8214.xml"/>
France</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<t>Email: bruno.decraene@orange.com<vspace blankLines="0" /></t> FC.7432.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4664.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4762.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.4761.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8317.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4193.xml"/>
</references>
</references>
<t>Bart Peirens<vspace blankLines="0" /> <section anchor="Acknowledgements" numbered="false" toc="default">
Proximus<vspace blankLines="0" /> <name>Acknowledgements</name>
Belgium</t> <t>The authors would like to acknowledge <contact fullname="Stefano Previd
<t>Email: bart.peirens@proximus.com<vspace blankLines="0" /></t> i"/>, <contact fullname="Dave Barach"/>, <contact fullname="Mark Townsley"/>, <c
ontact fullname="Peter Psenak"/>, <contact fullname="Thierry Couture"/>, <contac
t fullname="Kris Michielsen"/>, <contact fullname="Paul Wells"/>, <contact fulln
ame="Robert Hanzl"/>, <contact fullname="Dan Ye"/>, <contact fullname="Gaurav Da
wra"/>, <contact fullname="Faisal Iqbal"/>, <contact fullname="Jaganbabu Rajaman
ickam"/>, <contact fullname="David Toscano"/>, <contact fullname="Asif Islam"/>,
<contact fullname="Jianda Liu"/>, <contact fullname="Yunpeng Zhang"/>, <contact
fullname="Jiaoming Li"/>, <contact fullname="Narendra A.K"/>, <contact fullname
="Mike Mc Gourty"/>, <contact fullname="Bhupendra Yadav"/>, <contact fullname="S
herif Toulan"/>, <contact fullname="Satish Damodaran"/>, <contact fullname="John
Bettink"/>, <contact fullname="Kishore Nandyala Veera Venk"/>, <contact fullnam
e="Jisu Bhattacharya"/>, <contact fullname="Saleem Hafeez"/>, and <contact fulln
ame="Brian Carpenter"/>.</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<t>Hani Elmalky<vspace blankLines="0" /> <contact fullname="Daniel Bernier" >
Google<vspace blankLines="0" /> <organization>Bell Canada</organization>
United States of America</t> <address>
<t>Email: helmalky@google.com<vspace blankLines="0" /></t> <postal>
<country>Canada</country>
</postal>
<email>daniel.bernier@bell.ca</email>
</address>
</contact>
<t>Prem Jonnalagadda<vspace blankLines="0" /> <contact fullname="Dirk Steinberg" >
Barefoot Networks<vspace blankLines="0" /> <organization>Lapishills Consulting Limited</organization>
United States of America</t> <address>
<t>Email: prem@barefootnetworks.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Cyprus</country>
</postal>
<email>dirk@lapishills.com</email>
</address>
</contact>
<t>Milad Sharif<vspace blankLines="0" /> <contact fullname="Robert Raszuk" >
SambaNova Systems<vspace blankLines="0" /> <organization>Bloomberg LP</organization>
United States of America</t> <address>
<t>Email: milad.sharif@sambanova.ai<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>robert@raszuk.net</email>
</address>
</contact>
<t>David Lebrun<vspace blankLines="0" /> <contact fullname="Bruno Decraene" >
Google<vspace blankLines="0" /> <organization>Orange</organization>
Belgium</t> <address>
<t>Email: dlebrun@google.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>France</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</contact>
<t>Stefano Salsano<vspace blankLines="0" /> <contact fullname="Bart Peirens" >
Universita di Roma "Tor Vergata"<vspace blankLines="0" /> <organization>Proximus</organization>
Italy</t> <address>
<t>Email: stefano.salsano@uniroma2.it<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Belgium</country>
</postal>
<email>bart.peirens@proximus.com</email>
</address>
</contact>
<t>Ahmed AbdelSalam<vspace blankLines="0" /> <contact fullname="Hani Elmalky" >
Gran Sasso Science Institute<vspace blankLines="0" /> <organization>Google</organization>
Italy</t> <address>
<t>Email: ahmed.abdelsalam@gssi.it</t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>helmalky@google.com</email>
</address>
</contact>
<t>Gaurav Naik<vspace blankLines="0" /> <contact fullname="Prem Jonnalagadda" >
Drexel University<vspace blankLines="0" /> <organization>Barefoot Networks</organization>
United States of America</t> <address>
<t>Email: gn@drexel.edu<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>prem@barefootnetworks.com</email>
</address>
</contact>
<t>Arthi Ayyangar<vspace blankLines="0" /> <contact fullname="Milad Sharif" >
Arrcus, Inc<vspace blankLines="0" /> <organization>SambaNova Systems</organization>
United States of America</t> <address>
<t>Email: arthi@arrcus.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>milad.sharif@sambanova.ai</email>
</address>
</contact>
<t>Satish Mynam<vspace blankLines="0" /> <contact fullname="David Lebrun" >
Arrcus, Inc<vspace blankLines="0" /> <organization>Google</organization>
United States of America</t> <address>
<t>Email: satishm@arrcus.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Belgium</country>
</postal>
<email>dlebrun@google.com</email>
</address>
</contact>
<t>Wim Henderickx<vspace blankLines="0" /> <contact fullname="Stefano Salsano" >
Nokia<vspace blankLines="0" /> <organization>Universita di Roma "Tor Vergata"</organization>
Belgium</t> <address>
<t>Email: wim.henderickx@nokia.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Italy</country>
</postal>
<email>stefano.salsano@uniroma2.it</email>
</address>
</contact>
<t>Shaowen Ma<vspace blankLines="0" /> <contact fullname="Ahmed AbdelSalam" >
Juniper<vspace blankLines="0" /> <organization>Gran Sasso Science Institute</organization>
Singapore</t> <address>
<t>Email: mashao@juniper.net<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Italy</country>
</postal>
<email>ahmed.abdelsalam@gssi.it</email>
</address>
</contact>
<t>Ahmed Bashandy<vspace blankLines="0" /> <contact fullname="Gaurav Naik" >
Individual<vspace blankLines="0" /> <organization>Drexel University</organization>
United States of America</t> <address>
<t>Email: abashandy.ietf@gmail.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>gn@drexel.edu</email>
</address>
</contact>
<t>Francois Clad<vspace blankLines="0" /> <contact fullname="Arthi Ayyangar" >
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Arrcus, Inc</organization>
France</t> <address>
<t>Email: fclad@cisco.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>arthi@arrcus.com</email>
</address>
</contact>
<t>Kamran Raza<vspace blankLines="0" /> <contact fullname="Satish Mynam" >
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Arrcus, Inc</organization>
Canada</t> <address>
<t>Email: skraza@cisco.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>satishm@arrcus.com</email>
</address>
</contact>
<t>Darren Dukes<vspace blankLines="0" /> <contact fullname="Wim Henderickx" >
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Nokia</organization>
Canada</t> <address>
<t>Email: ddukes@cisco.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Belgium</country>
</postal>
<email>wim.henderickx@nokia.com</email>
</address>
</contact>
<t>Patrice Brissete <vspace blankLines="0" /> <contact fullname="Shaowen Ma" >
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Juniper</organization>
Canada</t> <address>
<t>Email: pbrisset@cisco.com<vspace blankLines="0" /></t> <postal>
<city></city>
<country>Singapore</country>
</postal>
<email>mashao@juniper.net</email>
</address>
</contact>
<t>Zafar Ali<vspace blankLines="0" /> <contact fullname="Ahmed Bashandy">
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Individual</organization>
United States of America</t> <address>
<t>Email: zali@cisco.com</t> <postal>
<city></city>
<country>United States of America</country>
</postal>
<email>abashandy.ietf@gmail.com</email>
</address>
</contact>
<t>Ketan Talaulikar<vspace blankLines="0" /> <contact fullname="Francois Clad">
Cisco Systems, Inc.<vspace blankLines="0" /> <organization>Cisco Systems, Inc.</organization>
India</t> <address>
<t>Email: ketant@cisco.com</t> <postal>
</section> <city></city>
</middle> <country>France</country>
<back> </postal>
<references title="Normative References"> <email>fclad@cisco.com</email>
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/referenc </address>
e.RFC.2119.xml"?--> </contact>
&RFC2119;
&RFC8174; <contact fullname="Kamran Raza">
&RFC8754; <organization>Cisco Systems, Inc.</organization>
&RFC2473; <address>
&RFC8200; <postal>
&RFC8402; <city></city>
&RFC6437; <country>Canada</country>
<reference anchor="IEEE.802.3_2018" target="https://ieeexplore.ieee. </postal>
org/document/8457469"> <email>skraza@cisco.com</email>
<front> </address>
<title>802.3-2018</title> </contact>
<author>
<organization>IEEE</organization> <contact fullname="Darren Dukes">
</author> <organization>Cisco Systems, Inc.</organization>
<date day="31" month="August" year="2018"/> <address>
<abstract> <postal>
<t>Ethernet local area network operation is specified fo <city></city>
r selected speeds of operation from 1 Mb/s to 400 Gb/s using a common media acce <country>Canada</country>
ss control (MAC) specification and management information base (MIB). The Carrie </postal>
r Sense Multiple Access with Collision Detection (CSMA/CD) MAC protocol specifie <email>ddukes@cisco.com</email>
s shared medium (half duplex) operation, as well as full duplex operation. Speed </address>
specific Media Independent Interfaces (MIIs) allow use of selected Physical Lay </contact>
er devices (PHY) for operation over coaxial, twisted pair or fiber optic cables,
or electrical backplanes. System considerations for multisegment shared access <contact fullname="Patrice Brissete" >
networks describe the use of Repeaters that are defined for operational speeds u <organization>Cisco Systems, Inc.</organization>
p to 1000 Mb/s. Local Area Network (LAN) operation is supported at all speeds. O <address>
ther specified capabilities include: various PHY types for access networks, PHYs <postal>
suitable for metropolitan area network applications, and the provision of power <city></city>
over selected twisted pair PHY types.</t> <country>Canada</country>
</abstract> </postal>
</front> <email>pbrisset@cisco.com</email>
<seriesInfo name="IEEE" value="802.3-2018"/> </address>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8457469"/> </contact>
</reference>
</references> <contact fullname="Zafar Ali" >
<references title="Informative References"> <organization>Cisco Systems, Inc.</organization>
&RFC4364; <address>
&NET_PGM_ILL; <postal>
&TILFA; <city></city>
&RFC8214; <country>United States of America</country>
&RFC7432; </postal>
&RFC4664; <email>zali@cisco.com</email>
&RFC4762; </address>
&RFC8126; </contact>
&RFC4761;
&RFC8317; <contact fullname="Ketan Talaulikar" >
&RFC4193; <organization>Cisco Systems, Inc.</organization>
</references> <address>
</back> <postal>
<city></city>
<country>India</country>
</postal>
<email>ketant@cisco.com</email> </address> </contact> </section>
</back>
</rfc> </rfc>
 End of changes. 190 change blocks. 
1763 lines changed or deleted 2313 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/