rfc9513xml2.original.xml   rfc9513.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="3"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc compact="yes"?> std"
<?rfc subcompact="no"?> consensus="true" docName="draft-ietf-lsr-ospfv3-srv6-extensions-15" number="9513
<rfc category="std" docName="draft-ietf-lsr-ospfv3-srv6-extensions-15" " ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true" tocD
ipr="trust200902"> epth="3"
symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="OSPFv3 Extensions for SRV6 ">OSPFv3 Extensions for <title abbrev="OSPFv3 Extensions for SRV6 ">OSPFv3 Extensions for
SRv6</title> Segment Routing over IPv6 (SRv6)</title>
<seriesInfo name="RFC" value="9513"/>
<author fullname="Zhenbin Li" initials="Z." surname="Li"> <author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>lizhenbin@huawei.com</email> <email>lizhenbin@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Zhibo Hu" initials="Z." surname="Hu"> <author fullname="Zhibo Hu" initials="Z." surname="Hu">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<email>huzhibo@huawei.com</email> <email>huzhibo@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Tala
<author fullname="Ketan Talaulikar" initials="K" role="editor" ulikar">
surname="Talaulikar">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant.ietf@gmail.com</email> <email>ketant.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P." surname="Psenak"> <author fullname="Peter Psenak" initials="P." surname="Psenak">
<organization>Cisco Systems</organization> <organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
</address> </address>
</author> </author>
<date year="2023" month="November" />
<date year=""/> <area>rtg</area>
<workgroup>lsr</workgroup>
<area>Routing</area>
<workgroup>Link State Routing</workgroup>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<keyword>OSPFv3</keyword> <keyword>OSPFv3</keyword>
<keyword>Segment Routing</keyword> <keyword>Segment Routing</keyword>
<keyword>SRv6</keyword> <keyword>SRv6</keyword>
<abstract> <abstract>
<t>The Segment Routing (SR) architecture allows a flexible definition of <t>The Segment Routing (SR) architecture allows a flexible definition of
the end-to-end path by encoding it as a sequence of topological elements the end-to-end path by encoding it as a sequence of topological elements
called segments. It can be implemented over an MPLS or IPv6 data plane. called segments. It can be implemented over an MPLS or IPv6 data plane.
This document describes the OSPFv3 extensions required to support This document describes the OSPFv3 extensions required to support
Segment Routing over the IPv6 data plane (SRv6).</t> SR over the IPv6 data plane.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>The Segment Routing (SR) architecture <xref target="RFC8402"/> <name>Introduction</name>
<t>The Segment Routing (SR) architecture <xref target="RFC8402" format="de
fault"/>
specifies how a node can steer a packet using an ordered list of specifies how a node can steer a packet using an ordered list of
instructions, called segments. These segments are identified using instructions called segments. These segments are identified using
Segment Identifiers (SIDs).</t> Segment Identifiers (SIDs).</t>
<t>SR can be instantiated on the IPv6 data plane through
<t>Segment Routing can be instantiated on the IPv6 data plane through the use of the Segment Routing Header (SRH) defined in <xref target="RFC87
the use of the Segment Routing Header (SRH) defined in <xref 54" format="default"/>. SR instantiation on the IPv6 data plane
target="RFC8754"/>. Segment Routing instantiation on the IPv6 dataplane
is referred to as SRv6.</t> is referred to as SRv6.</t>
<t>The network programming paradigm for SRv6 is specified in <xref target=
<t>The network programming paradigm for SRv6 is specified in <xref "RFC8986" format="default"/>. It describes how any behavior can be bound to a SI
target="RFC8986"/>. It describes how any behavior can be bound to a SID D
and how any network program can be expressed as a combination of SIDs. and how any network program can be expressed as a combination of SIDs.
It also describes several well-known behaviors that can be bound to SRv6 It also describes several well-known behaviors that can be bound to SRv6
SIDs.</t> SIDs.</t>
<t>This document specifies OSPFv3 extensions to support SRv6 <t>This document specifies OSPFv3 extensions to support SRv6
capabilities as defined in <xref target="RFC8986"/>, <xref capabilities as defined in <xref target="RFC8986" format="default"/>, <xre
target="RFC8754"/>, and <xref target="RFC9259"/>. The extensions include f target="RFC8754" format="default"/>, and <xref target="RFC9259" format="defaul
t"/>. The extensions include
advertisement of an OSPFv3 router's SRv6 capabilities, SRv6 Locators, advertisement of an OSPFv3 router's SRv6 capabilities, SRv6 Locators,
and required SRv6 SIDs along with their supported endpoint behaviors. and required SRv6 SIDs along with their supported Endpoint behaviors.
Familiarity with <xref target="RFC8986"/> is necessary to understand the Familiarity with <xref target="RFC8986" format="default"/> is necessary to
understand the
extensions specified in this document.</t> extensions specified in this document.</t>
<t>At a high level, the extensions to OSPFv3 are comprised of the <t>At a high level, the extensions to OSPFv3 are comprised of the
following:<list style="numbers"> following:</t>
<t>An SRv6 Capabilities TLV to advertise the SRv6 features and SRH <ol spacing="normal" type="1"><li>An SRv6 Capabilities TLV to advertise th
operations supported by an OSPFv3 router</t> e SRv6 features and SRH
operations supported by an OSPFv3 router.</li>
<t>Several sub-TLVs to advertise various SRv6 Maximum SID <li>Several sub-TLVs to advertise various SRv6 Maximum SID
Depths.</t> Depths.</li>
<li>An SRv6 Locator TLV using an SRv6 Locator Link State
<t>An SRv6 Locator TLV using an SRv6 Locator Link-State Advertisement (LSA) to advertise the SRv6 Locator -- a form of
Advertisement (LSA) to advertise the SRv6 Locator - a form of
summary address for the IGP algorithm-specific SIDs instantiated on summary address for the IGP algorithm-specific SIDs instantiated on
an OSPFv3 router</t> an OSPFv3 router.</li>
<li>TLVs and sub-TLVs to advertise the SRv6 SIDs instantiated on an
<t>TLVs and Sub-TLVs to advertise the SRv6 SIDs instantiated on an OSPFv3 router along with their Endpoint behaviors.</li>
OSPFv3 router along with their endpoint behaviors</t> </ol>
</list></t> <section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="capability" numbered="true" toc="default">
<section anchor="capability" title="SRv6 Capabilities TLV"> <name>SRv6 Capabilities TLV</name>
<t>The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise <t>The SRv6 Capabilities TLV is used by an OSPFv3 router to advertise
its support for the SR Segment Endpoint Node <xref target="RFC8754"/> its support for the SR Segment Endpoint Node <xref target="RFC8754" format ="default"/>
functionality along with its SRv6-related capabilities. This is an functionality along with its SRv6-related capabilities. This is an
optional top level TLV of the OSPFv3 Router Information LSA <xref optional top-level TLV of the OSPFv3 Router Information LSA <xref target="
target="RFC7770"/> which MUST be advertised by an SRv6-enabled RFC7770" format="default"/> that <bcp14>MUST</bcp14> be advertised by an SRv6-en
abled
router.</t> router.</t>
<t>This TLV <bcp14>MUST</bcp14> be advertised only once in the OSPFv3 Rout
<t>This TLV MUST be advertised only once in the OSPFv3 Router er
Information LSA. When multiple SRv6 Capabilities TLVs are received from Information LSA. When multiple SRv6 Capabilities TLVs are received from
a given router, the receiver MUST use the first occurrence of the TLV in a given router, the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV in
the OSPFv3 Router Information LSA. If the SRv6 Capabilities TLV appears the OSPFv3 Router Information LSA. If the SRv6 Capabilities TLV appears
in multiple OSPFv3 Router Information LSAs that have different flooding in multiple OSPFv3 Router Information LSAs that have different flooding
scopes, the TLV in the OSPFv3 Router Information LSA with the scopes, the TLV in the OSPFv3 Router Information LSA with the
area-scoped flooding scope MUST be used. If the SRv6 Capabilities TLV area-scoped flooding scope <bcp14>MUST</bcp14> be used. If the SRv6 Capabi lities TLV
appears in multiple OSPFv3 Router Information LSAs that have the same appears in multiple OSPFv3 Router Information LSAs that have the same
flooding scope, the TLV in the OSPFv3 Router Information LSA with the flooding scope, the TLV in the OSPFv3 Router Information LSA with the
numerically smallest Link State ID MUST be used and subsequent instances numerically smallest Link State ID <bcp14>MUST</bcp14> be used, and subseq
of the TLV MUST be ignored.</t> uent instances
of the TLV <bcp14>MUST</bcp14> be ignored.</t>
<t>The OSPFv3 Router Information LSA can be advertised at any of the <t>The OSPFv3 Router Information LSA can be advertised at any of the
defined flooding scopes (link, area, or Autonomous System (AS)). For the defined flooding scopes (link, area, or Autonomous System (AS)).
For the
purpose of SRv6 Capabilities TLV advertisement, area-scoped flooding is purpose of SRv6 Capabilities TLV advertisement, area-scoped flooding is
REQUIRED. Link and AS-scoped flooding is OPTIONAL.</t> <bcp14>REQUIRED</bcp14>. Link and AS-scoped flooding is <bcp14>OPTIONAL</b
cp14>.</t>
<t>The format of OSPFv3 SRv6 Capabilities TLV is shown below:</t> <t>The format of the OSPFv3 SRv6 Capabilities TLV is shown below:</t>
<figure anchor="SRV6CAPFMT">
<figure anchor="SRV6CAPFMT" title="SRv6 Capabilities TLV"> <name>SRv6 Capabilities TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="center" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs... | Sub-TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>Where:<list style="symbols"> <t>where:</t>
<t>Type: 2-octet field. The value for this type is 20.</t> <dl newline="false">
<dt>Type:</dt><dd>2-octet field. The value for this type is 20.</dd>
<t>Length: 2-octet field. The total length (in octets) of the value <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the v
portion of the TLV including nested Sub-TLVs.</t> alue
portion of the TLV, including nested sub-TLVs.</dd>
<t>Reserved: 2-octet field. It MUST be set to 0 on transmission and <dt>Reserved:</dt><dd>2-octet field. It <bcp14>MUST</bcp14> be set to 0
MUST be ignored on receipt.</t> on transmission and
<bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>Flags: 2-octet field. The flags are defined as follows: <figure> <dt>Flags:</dt><dd><t>2-octet field. The flags are defined as follows:
<artwork><![CDATA[ 0 1 </t>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 <artwork name="" type="" align="left" alt=""><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1
| |O| | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> where: <list style="symbols"> | |O| |
<t>O-flag: If set, then the router is capable of supporting the +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
O-bit in the SRH flags, as specified in <xref
target="RFC9259"/>.</t>
<t>Other flags are not defined and are reserved for future use. -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]&gt;&lt;/artwork&gt;
They MUST be set to 0 on transmission and MUST be ignored on <t>where:</t>
receipt.</t>
</list></t>
</list></t>
<t>The SRv6 Capabilities TLV may contain optional Sub-TLVs. No Sub-TLVs <dl newline="false">
<dt>O-flag:</dt><dd>If set, then the router is capable of supporting
the
O-flag in the SRH flags, as specified in <xref target="RFC9259" fo
rmat="default"/>.</dd>
<dt>Other flags are not defined and are reserved for future use.
They <bcp14>MUST</bcp14> be set to 0 on transmission and
<bcp14>MUST</bcp14> be ignored on receipt.</dt><dd></dd>
</dl>
</dd>
</dl>
<t>The SRv6 Capabilities TLV may contain optional sub-TLVs. No sub-TLVs
are defined in this specification.</t> are defined in this specification.</t>
</section> </section>
<section anchor="algorithm" numbered="true" toc="default">
<section anchor="algorithm" title="Advertisement of Supported Algorithms"> <name>Advertisement of Supported Algorithms</name>
<t>An SRv6-enabled OSPFv3 router advertises its algorithm support using <t>An SRv6-enabled OSPFv3 router advertises its algorithm support using
the SR-Algorithm TLV defined in <xref target="RFC8665"/> as described in the SR-Algorithm TLV defined in <xref target="RFC8665" format="default"/>
<xref target="RFC8666"/>.</t> and as described in
<xref target="RFC8666" format="default"/>.</t>
</section> </section>
<section anchor="SRH-limits" numbered="true" toc="default">
<section anchor="SRH-limits" <name>Advertisement of Maximum SRv6 SID Depths</name>
title="Advertisement of Maximum SRv6 SID Depths">
<t>An SRv6-enabled router may have different capabilities and limits <t>An SRv6-enabled router may have different capabilities and limits
related to SRH processing and these need to be advertised to other related to SRH processing. These need to be advertised to other
OSPFv3 routers in the SRv6 domain.</t> OSPFv3 routers in the SRv6 domain.</t>
<t><xref target="RFC8476" format="default"/> defines the means to advertis
<t><xref target="RFC8476"/> defines the means to advertise node and link e node- and link-specific values for Maximum SID Depth (MSD) types. Node MSDs ar
specific values for Maximum SID Depth (MSD) types. Node MSDs are e
advertised using the Node MSD TLV in the OSPFv3 Router Information LSA advertised using the Node MSD TLV in the OSPFv3 Router Information LSA
<xref target="RFC7770"/> while Link MSDs are advertised using the Link <xref target="RFC7770" format="default"/>, while Link MSDs are advertised
MSD Sub-TLV of the Router-Link TLV <xref target="RFC8362"/>. The format using the Link
of the MSD types for OSPFv3 is defined in <xref target="RFC8476"/>.</t> MSD sub-TLV of the Router-Link TLV <xref target="RFC8362" format="default"
/>. The format
<t>The MSD types for SRv6 that are defined in section 4 of <xref of the MSD types for OSPFv3 is defined in <xref target="RFC8476" format="d
target="RFC9352"/> for IS-IS are also used by OSPFv3. These MSD Types efault"/>.</t>
are allocated under the IGP MSD Types registry maintained by IANA that <t>The MSD types for SRv6 that are defined in <xref target="RFC9352" secti
are shared by IS-IS and OSPF. They are described below:</t> onFormat="of" section="4"/> for IS-IS are also used by OSPFv3. These MSD types
are allocated in the "IGP MSD-Types" registry maintained by IANA and
<section title="Maximum Segments Left MSD Type"> are shared by IS-IS and OSPF. They are described in the subsections below.
</t>
<section numbered="true" toc="default">
<name>Maximum Segments Left MSD Type</name>
<t>The Maximum Segments Left MSD Type signals the maximum value of the <t>The Maximum Segments Left MSD Type signals the maximum value of the
"Segments Left" field of the SRH of a received packet before applying Segments Left field of the SRH of a received packet before applying
the Endpoint behavior associated with a SID. If no value is the Endpoint behavior associated with a SID. If no value is
advertised, the supported value is assumed to be 0.</t> advertised, the supported value is assumed to be 0.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Maximum End Pop MSD Type"> <name>Maximum End Pop MSD Type</name>
<t>The Maximum End Pop MSD Type signals the maximum number of SIDs in <t>The Maximum End Pop MSD Type signals the maximum number of SIDs in
the SRH to which the router can apply "Penultimate Segment Pop (PSP) the SRH to which the router can apply "Penultimate Segment Pop (PSP)
of the SRH" or "Ultimate Segment Pop (USP) of the SRH", as defined in of the SRH" or "Ultimate Segment Pop (USP) of the SRH", which are flavor
<xref target="RFC8986"/> flavors. If the advertised value is zero or s defined in
no value is advertised, then the router cannot apply PSP or USP <xref target="RFC8986" format="default"/>. If the advertised value is ze
ro or
no value is advertised, then the router cannot apply the PSP or USP
flavors.</t> flavors.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Maximum H.Encaps MSD Type"> <name>Maximum H.Encaps MSD Type</name>
<t>The Maximum H.Encaps MSD Type signals the maximum number of SIDs <t>The Maximum H.Encaps MSD Type signals the maximum number of SIDs
that can be added as part of the "H.Encaps" behavior as defined in that can be added as part of the H.Encaps behavior as defined in
<xref target="RFC8986"/>. If the advertised value is zero or no value <xref target="RFC8986" format="default"/>. If the advertised value is ze
is advertised then the headend can apply an SR Policy that only ro or no value
contains one segment, without inserting any SRH. A non-zero SRH Max is advertised, then the headend can apply an SR Policy that only
H.encaps MSD indicates that the headend can insert an SRH with SIDs up contains one segment without inserting any SRH. A non-zero SRH Max
H.Encaps MSD indicates that the headend can insert an SRH with SIDs up
to the advertised value.</t> to the advertised value.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Maximum End D MSD Type"> <name>Maximum End D MSD Type</name>
<t>The Maximum End D MSD Type specifies the maximum number of SIDs <t>The Maximum End D MSD Type specifies the maximum number of SIDs
present in an SRH when performing decapsulation. These include, but present in an SRH when performing decapsulation. These include, but
are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and are not limited to, End.DX6, End.DT4, End.DT46, End with USD, and
End.X with USD as defined in <xref target="RFC8986"/>. If the End.X with USD as defined in <xref target="RFC8986" format="default"/>. If the
advertised value is zero or no value is advertised, then the router advertised value is zero or no value is advertised, then the router
cannot apply any behavior that results in decapsulation and forwarding cannot apply any behavior that results in decapsulation and forwarding
of the inner packet when the outer IPv6 header contains an SRH.</t> of the inner packet when the outer IPv6 header contains an SRH.</t>
</section> </section>
</section> </section>
<section anchor="SRv6-SID" numbered="true" toc="default">
<section anchor="SRv6-SID" title="SRv6 SIDs and Reachability"> <name>SRv6 SIDs and Reachability</name>
<t>An SRv6 Segment Identifier (SID) is 128 bits and consists of Locator, <t>An SRv6 SID is 128 bits and consists of locator,
Function, and Argument parts as described in <xref function, and argument parts as described in <xref target="RFC8986" format
target="RFC8986"/>.</t> ="default"/>.</t>
<t>An OSPFv3 router is provisioned with algorithm-specific locators for <t>An OSPFv3 router is provisioned with algorithm-specific locators for
each algorithm supported by that router. Each locator is a covering each algorithm supported by that router. Each locator is a covering
prefix for all SIDs provisioned on that router that have the matching prefix for all SIDs provisioned on that router that have the matching
algorithm.</t> algorithm.</t>
<t>Locators <bcp14>MUST</bcp14> be advertised within an SRv6 Locator TLV (
<t>Locators MUST be advertised within an SRv6 Locator TLV (see <xref see <xref target="LOCTLV" format="default"/>) using an SRv6 Locator LSA (see <xr
target="LOCTLV"/>) using an SRv6 Locator LSA (see <xref ef target="LOCLSA" format="default"/>). The SRv6 Locator LSA is introduced inste
target="LOCLSA"/>). The SRv6 Locator LSA is introduced instead of ad of
reusing the respective Extended Prefix LSAs <xref target="RFC8362"/> for reusing the respective Extended Prefix LSAs <xref target="RFC8362" format=
"default"/> for
a clear distinction between the two different types of reachability a clear distinction between the two different types of reachability
advertisements (viz., the base OSPFv3 prefix reachability advertisements advertisements (viz., the base OSPFv3 prefix reachability advertisements
and the SRv6 Locator reachability advertisements).</t> and the SRv6 Locator reachability advertisements).</t>
<t>Forwarding entries for the locators advertised in the SRv6 Locator <t>Forwarding entries for the locators advertised in the SRv6 Locator
TLV MUST be installed in the forwarding plane of receiving SRv6-capable TLV <bcp14>MUST</bcp14> be installed in the forwarding plane of receiving SRv6-capable
routers when the associated algorithm is supported by the receiving routers when the associated algorithm is supported by the receiving
OSPFv3 router. Locators can be of different route types that map to OSPFv3 router. Locators can be of different route types that map to
existing OSPFv3 LSA types - Intra-Area, Inter-Area, External, and NSSA. existing OSPFv3 LSA types: Intra-Area, Inter-Area, External, and Not-So-St ubby Area (NSSA).
The advertisement and propagation of the SRv6 Locator LSAs also follow The advertisement and propagation of the SRv6 Locator LSAs also follow
the OSPFv3 <xref target="RFC5340"/> specifications for the respective the OSPFv3 <xref target="RFC5340" format="default"/> specifications for th e respective
LSA types. The processing of the prefix advertised in the SRv6 Locator LSA types. The processing of the prefix advertised in the SRv6 Locator
TLV, the calculation of its reachability, and the installation in the TLV, the calculation of its reachability, and the installation in the
forwarding plane follows the OSPFv3 <xref target="RFC5340"/> forwarding plane follows the OSPFv3 <xref target="RFC5340" format="default "/>
specifications for the respective LSA types.</t> specifications for the respective LSA types.</t>
<t>Locators associated with algorithms 0 and 1 (refer to <xref target="RFC
<t>Locators associated with algorithms 0 and 1 (refer section 3.1.1 of 8402" sectionFormat="of" section="3.1.1"/>) <bcp14>SHOULD</bcp14> also be advert
<xref target="RFC8402"/>) SHOULD also be advertised using OSPFv3 ised using Extended LSA types with extended TLVs <xref target="RFC8362" format="
Extended LSA types with extended TLVs <xref target="RFC8362"/> so that default"/> so that
routers that do not support SRv6 will install a forwarding entry for routers that do not support SRv6 will install a forwarding entry for
SRv6 traffic matching those locators. When operating in Extended LSA SRv6 traffic matching those locators. When operating in Extended LSA
sparse-mode <xref target="RFC8362"/>, these locators SHOULD be also sparse-mode <xref target="RFC8362" format="default"/>, these locators <bcp
advertised using legacy OSPFv3 LSAs <xref target="RFC5340"/>.</t> 14>SHOULD</bcp14> also be
advertised using Legacy LSAs <xref target="RFC5340" format="default"/>.</t
>
<t>When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs <t>When SRv6 Locators are also advertised as Intra-Area-Prefix-LSAs
and/or E-Intra-Area-Prefix-LSAs, the SRv6 Locator MUST be considered as and/or E-Intra-Area-Prefix-LSAs, the SRv6 Locator <bcp14>MUST</bcp14> be c
a prefix associated with the router and the referenced LSA type MUST onsidered as
a prefix associated with the router, and the referenced LSA type <bcp14>MU
ST</bcp14>
point to the Router LSA of the advertising router as specified in point to the Router LSA of the advertising router as specified in
Section 4.4.3.9 of <xref target="RFC5340"/>.</t> <xref target="RFC5340" sectionFormat="of" section="4.4.3.9"/>.</t>
<t>In cases where a locator advertisement is received both in a prefix <t>In cases where a locator advertisement is received both in a prefix
reachability advertisement (i.e., via legacy OSPFv3 LSAs and/or Extended reachability advertisement (i.e., via Legacy LSAs and/or Extended
Prefix TLVs using OSPFv3 Extended LSAs) and an SRv6 Locator TLV, the Prefix TLVs using Extended LSAs) and an SRv6 Locator TLV, the
prefix reachability advertisement in the OSPFv3 legacy LSA or Extended prefix reachability advertisement in the Legacy LSA or Extended
LSA MUST be preferred over the advertisement in the SRv6 Locator TLV LSA <bcp14>MUST</bcp14> be preferred over the advertisement in the SRv6 Lo
when installing entries in the forwarding plane. This is to prevent cator TLV
inconsistent forwarding entries between SRv6 capable and SRv6 incapable when installing entries in the forwarding plane. This prevents
inconsistent forwarding entries between SRv6-capable and SRv6-incapable
OSPFv3 routers. Such preference for prefix reachability advertisement OSPFv3 routers. Such preference for prefix reachability advertisement
does not have any impact on the rest of the data advertised in the SRv6 does not have any impact on the rest of the data advertised in the SRv6
Locator TLV.</t> Locator TLV.</t>
<t>SRv6 SIDs are advertised as sub-TLVs in the SRv6 Locator TLV except
<t>SRv6 SIDs are advertised as Sub-TLVs in the SRv6 Locator TLV except for SRv6 End.X SIDs and LAN End.X SIDs, which are associated with a specif
for SRv6 End.X SIDs/LAN End.X SIDs which are associated with a specific ic
Neighbor/Link and are therefore advertised as Sub-TLVs of the neighbor/link and are therefore advertised as sub-TLVs of the
E-Router-Link TLV.</t> E-Router-Link TLV.</t>
<t>SRv6 SIDs received from other OSFPv3 routers are not directly <t>SRv6 SIDs received from other OSFPv3 routers are not directly
routable and MUST NOT be installed in the forwarding plane. Reachability routable and <bcp14>MUST NOT</bcp14> be installed in the forwarding plane. Reachability
to SRv6 SIDs depends upon the existence of a covering locator.</t> to SRv6 SIDs depends upon the existence of a covering locator.</t>
<t>Adherence to the rules defined in this section will ensure that SRv6 <t>Adherence to the rules defined in this section will ensure that SRv6
SIDs associated with a supported algorithm will be forwarded correctly, SIDs associated with a supported algorithm will be forwarded correctly,
while SRv6 SIDs associated with an unsupported algorithm will be while SRv6 SIDs associated with an unsupported algorithm will be
dropped. NOTE: The drop behavior depends on the absence of a dropped.</t>
default/summary route matching the locator prefix.</t> <aside><t>NOTE: The drop behavior depends on the absence of a
default/summary route matching the locator prefix.</t></aside>
<t>If the locator associated with SRv6 SID advertisements is the longest <t>If the locator associated with SRv6 SID advertisements is the longest
prefix match installed in the forwarding plane for those SIDs, this will prefix match installed in the forwarding plane for those SIDs, this will
ensure correct forwarding. Network operators should take steps to make ensure correct forwarding. Network operators should take steps to make
sure that this requirement is not compromised. For example, the sure that this requirement is not compromised. For example, the
following situations should be avoided:</t> following situations should be avoided:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Another locator associated with a different algorithm is the
<t>Another locator associated with a different algorithm is the longest prefix match.</li>
longest prefix match</t> <li>Another prefix advertised via Legacy or Extended LSA
advertisement is the longest prefix match.</li>
<t>Another prefix advertised via OSPFv3 legacy or Extended LSA </ul>
advertisement is the longest prefix match</t> <section anchor="SRV6FA" numbered="true" toc="default">
</list></t> <name>SRv6 Flexible Algorithm</name>
<t><xref target="RFC9350" format="default"/> specifies IGP Flexible Algo
<section anchor="SRV6FA" title="SRv6 Flexible Algorithm"> rithm
<t><xref target="RFC9350"/> specifies IGP Flexible Algorithm mechanisms for OSPFv3.
mechanisms for OSPFv3. Section 14.2 of <xref target="RFC9350"/> <xref target="RFC9350" sectionFormat="of" section="14.2"/>
explains SRv6 forwarding for Flexible Algorithm and analogous explains SRv6 forwarding for Flexible Algorithms, and analogous
procedures apply for supporting SRv6 Flexible Algorithm using OSPFv3. procedures apply for supporting SRv6 Flexible Algorithms using OSPFv3.
When the algorithm value that is advertised in the SRv6 Locator TLV When the algorithm value that is advertised in the SRv6 Locator TLV
(refer to <xref target="LOCTLV"/>) represents a Flexible Algorithm, (refer to <xref target="LOCTLV" format="default"/>) represents a Flexibl
the procedures described in section 14.2 of <xref target="RFC9350"/> e Algorithm,
the procedures described in <xref target="RFC9350" sectionFormat="of" se
ction="14.2"/>
are followed for the programming of those specific SRv6 Locators.</t> are followed for the programming of those specific SRv6 Locators.</t>
<t>Locators associated with Flexible Algorithms <bcp14>SHOULD NOT</bcp14
<t>Locators associated with Flexible Algorithms SHOULD NOT be > be
advertised in the base OSPFv3 prefix reachability advertisements. advertised in the base OSPFv3 prefix reachability advertisements.
Advertising the Flexible Algorithm locator in a regular prefix Advertising the Flexible Algorithm locator in a regular prefix
reachability advertisement would make it available for non-Flexible reachability advertisement would make it available for non-Flexible
Algorithm forwarding (i.e., algorithm 0).</t> Algorithm forwarding (i.e., algorithm 0).</t>
<t>The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as specified in <xr
<t>The procedures for OSPFv3 Flexible Algorithm for SR-MPLS, as ef target="RFC9350" format="default"/>, also apply for SRv6; these procedures in
specified in <xref target="RFC9350"/>, like ASBR reachability, clude a) ASBR reachability,
inter-area, external, and NSSA prefix advertisements and their use in b) inter-area, external, and NSSA prefix advertisements, and c) the use of
Flexible Algorithm route computation also apply for SRv6.</t> those prefix advertisements in Flexible Algorithm route computation.</t>
</section> </section>
</section> </section>
<section anchor="ANYCAST" numbered="true" toc="default">
<section anchor="ANYCAST" title="Advertisement of Anycast Property"> <name>Advertisement of Anycast Property</name>
<t>Both prefixes and SRv6 Locators may be configured as anycast and as <t>Both prefixes and SRv6 Locators may be configured as anycast, and as
such the same value can be advertised by multiple routers. It is useful such, the same value can be advertised by multiple routers. It is useful
for other routers to know that the advertisement is for an anycast for other routers to know that the advertisement is for an anycast
identifier.</t> identifier.</t>
<t>The AC-bit (value 0x80) in the OSPFv3 PrefixOptions field <xref target=
<t>A new bit in OSPFv3 PrefixOptions <xref target="RFC5340"/> is defined "RFC5340" format="default"/> is defined
to advertise the anycast property:</t> to advertise the anycast property:</t>
<figure anchor="PFXOPTIONS">
<t><figure anchor="PFXOPTIONS" title="OSPFv3 Prefix Options Field"> <name>OSPFv3 Prefix Options Field</name>
<artwork><![CDATA[ <artwork name="" type="" alt="" align="center"><![CDATA[
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
|AC|EL| N|DN| P| x|LA|NU| |AC|EL| N|DN| P| x|LA|NU|
+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+
]]></artwork> ]]></artwork>
</figure></t> --+--+--+--+--+--+--+--+
</figure>
<t>Value: 0x80</t>
<t>Description: Anycast (AC-bit)</t>
<t>When the prefix/SRv6 Locator is configured as anycast, the AC-bit <t>When the prefix/SRv6 Locator is configured as anycast, the AC-bit
MUST be set. Otherwise, this flag MUST be clear.</t> <bcp14>MUST</bcp14> be set. Otherwise, this flag <bcp14>MUST</bcp14> be cl
ear.</t>
<t>The AC-bit MUST be preserved when re-advertising the prefix/SRv6 <t>The AC-bit <bcp14>MUST</bcp14> be preserved when re-advertising the pre
fix/SRv6
Locator across areas.</t> Locator across areas.</t>
<t>The AC-bit and the N-bit <bcp14>MUST NOT</bcp14> both be set. If the N-
<t>The AC-bit and the N-bit MUST NOT both be set. If both N-bit and bit and
AC-bit are set in the prefix/SRv6 Locator advertisement, the receiving AC-bit are both set in the prefix/SRv6 Locator advertisement, the receivin
routers MUST ignore the N-bit.</t> g
routers <bcp14>MUST</bcp14> ignore the N-bit.</t>
<t>The same prefix/SRv6 Locator can be advertised by multiple routers. <t>The same prefix/SRv6 Locator can be advertised by multiple routers.
If at least one of them sets the AC-bit in its advertisement, the If at least one of them sets the AC-bit in its advertisement, the
prefix/SRv6 Locator is considered as anycast.</t> prefix/SRv6 Locator is considered as anycast.</t>
<t>A prefix/SRv6 Locator that is advertised by a single node and without <t>A prefix/SRv6 Locator that is advertised by a single node and without
an AC-bit is considered node-specific.</t> an AC-bit is considered node-specific.</t>
<t>All the nodes advertising the same anycast SRv6 Locator <bcp14>MUST</bc
<t>All the nodes advertising the same anycast SRv6 Locator MUST p14>
instantiate the exact same set of SIDs under that anycast SRv6 Locator. instantiate the exact same set of SIDs under that anycast SRv6 Locator.
Failure to do so may result in traffic being dropped or misrouted.</t> Failure to do so may result in traffic being dropped or misrouted.</t>
<t>The PrefixOptions field is common to the prefix reachability <t>The PrefixOptions field is common to the prefix reachability
advertisements (i.e., the base OSPFv3 prefix LSA types defined in <xref advertisements (i.e., the base OSPFv3 prefix LSA types defined in <xref ta
target="RFC5340"/> and the OSPFv3 Extended Prefix TLV types defined in rget="RFC5340" format="default"/>, the OSPFv3 Extended Prefix TLV types defined
<xref target="RFC8362"/>) and the SRv6 Locator TLV advertisements in
specified in <xref target="LOCTLV"/> of this document. When a router <xref target="RFC8362" format="default"/>), and the SRv6 Locator TLV adver
tisements
specified in <xref target="LOCTLV" format="default"/> of this document. Wh
en a router
originates both the prefix reachability advertisement and the SRv6 originates both the prefix reachability advertisement and the SRv6
Locator advertisement for a given prefix, the router SHOULD advertise Locator advertisement for a given prefix, the router <bcp14>SHOULD</bcp14> advertise
the same PrefixOptions bits in both advertisements. In the case of any the same PrefixOptions bits in both advertisements. In the case of any
inconsistency between the PrefixOptions advertised in the SRv6 Locator inconsistency between the PrefixOptions advertised in the SRv6 Locator
and in the prefix reachability advertisements, the ones advertised in and in the prefix reachability advertisements, the ones advertised in
prefix reachability advertisement MUST be preferred.</t> the prefix reachability advertisement <bcp14>MUST</bcp14> be preferred.</t >
</section> </section>
<section anchor="LOCLSA" numbered="true" toc="default">
<section anchor="LOCLSA" title="SRv6 Locator LSA"> <name>SRv6 Locator LSA</name>
<t>The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are <t>The SRv6 Locator LSA has a function code of 42. The S1/S2 bits are
dependent on the desired flooding scope for the LSA. The flooding scope dependent on the desired flooding scope for the LSA. The flooding scope
of the SRv6 Locator LSA depends on the scope of the advertised SRv6 of the SRv6 Locator LSA depends on the scope of the advertised SRv6
Locator and is under the control of the advertising router. The U-bit Locator and is under the control of the advertising router. The U-bit
will be set indicating that the LSA should be flooded even if it is not will be set indicating that the LSA should be flooded even if it is not
understood.</t> understood.</t>
<t>Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router, and
<t>Multiple SRv6 Locator LSAs can be advertised by an OSPFv3 router and
they are distinguished by their Link State IDs (which are chosen they are distinguished by their Link State IDs (which are chosen
arbitrarily by the originating router).</t> arbitrarily by the originating router).</t>
<t>The format of the SRv6 Locator LSA is shown below:</t>
<t>The format of SRv6 Locator LSA is shown below:</t> <figure anchor="LOCLSAFMT">
<name>SRv6 Locator LSA</name>
<t><figure anchor="LOCLSAFMT" title="SRv6 Locator LSA"> <artwork name="" type="" align="center" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age |U|S12| Function Code |
| LS age |U|S12| Function Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID |
| Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router |
| Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number |
| LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length |
| LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| | +- TLVs -+
+- TLVs -+ | ... |
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The format of the TLVs within the body of the SRv6 Locator LSA is the <t>The format of the TLVs within the body of the SRv6 Locator LSA is the
same as the format used by <xref target="RFC3630"/>. The variable TLV same as the format used by <xref target="RFC3630" format="default"/>. The variable TLV
section consists of one or more nested TLV tuples. Nested TLVs are also section consists of one or more nested TLV tuples. Nested TLVs are also
referred to as Sub-TLVs. The format of each TLV is:</t> referred to as sub-TLVs. The format of each TLV is:</t>
<figure anchor="TLVFMT">
<t><figure anchor="TLVFMT" title="SRv6 Locator LSA TLV Format"> <name>SRv6 Locator LSA TLV Format</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="center" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... | | Value... |
. . . .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t>The Length field defines the length of the value portion in octets <t>The Length field defines the length of the value portion in octets
(thus, a TLV with no value portion would have a length of 0). The TLV is (thus, a TLV with no value portion would have a length of 0). The TLV is
padded to 4-octet alignment; padding is not included in the Length field padded to 4-octet alignment; padding is not included in the Length field
(so a 3-octet value would have a length of 3, but the total size of the (so a 3-octet value would have a length of 3, but the total size of the
TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For
example, a 1-byte value would have the Length field set to 1 and 3 example, a 1-byte value would have the Length field set to 1, and 3
octets of padding would be added to the end of the value portion of the octets of padding would be added to the end of the value portion of the
TLV. The padding is composed of zeros.</t> TLV. The padding is composed of zeros.</t>
<section anchor="LOCTLV" numbered="true" toc="default">
<section anchor="LOCTLV" title="SRv6 Locator TLV"> <name>SRv6 Locator TLV</name>
<t>The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA <t>The SRv6 Locator TLV is a top-level TLV of the SRv6 Locator LSA
that is used to advertise an SRv6 Locator, its attributes, and SIDs that is used to advertise an SRv6 Locator, its attributes, and SIDs
associated with it. Multiple SRv6 Locator TLVs MAY be advertised in associated with it. Multiple SRv6 Locator TLVs <bcp14>MAY</bcp14> be adv ertised in
each SRv6 Locator LSA. However, since the S12 bits define the flooding each SRv6 Locator LSA. However, since the S12 bits define the flooding
scope, the LSA flooding scope has to satisfy the application-specific scope, the LSA flooding scope has to satisfy the application-specific
requirements for all the locators included in a single SRv6 Locator requirements for all the locators included in a single SRv6 Locator
LSA.</t> LSA.</t>
<t>When multiple SRv6 Locator TLVs are received from a given router in <t>When multiple SRv6 Locator TLVs are received from a given router in
an SRv6 Locator LSA for the same Locator, the receiver MUST use the an SRv6 Locator LSA for the same locator, the receiver <bcp14>MUST</bcp1 4> use the
first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for first occurrence of the TLV in the LSA. If the SRv6 Locator TLV for
the same Locator appears in multiple SRv6 Locator LSAs that have the same locator appears in multiple SRv6 Locator LSAs that have
different flooding scopes, the TLV in the SRv6 Locator LSA with the different flooding scopes, the TLV in the SRv6 Locator LSA with the
area-scoped flooding scope MUST be used. If the SRv6 Locator TLV for area-scoped flooding scope <bcp14>MUST</bcp14> be used. If the SRv6 Loca
the same Locator appears in multiple SRv6 Locator LSAs that have the tor TLV for
the same locator appears in multiple SRv6 Locator LSAs that have the
same flooding scope, the TLV in the SRv6 Locator LSA with the same flooding scope, the TLV in the SRv6 Locator LSA with the
numerically smallest Link-State ID MUST be used and subsequent numerically smallest Link State ID <bcp14>MUST</bcp14> be used, and subs
instances of the TLV MUST be ignored.</t> equent
instances of the TLV <bcp14>MUST</bcp14> be ignored.</t>
<t>The format of SRv6 Locator TLV is shown below:</t> <t>The format of the SRv6 Locator TLV is shown below:</t>
<figure anchor="LOCTLVFMT">
<t><figure anchor="LOCTLVFMT" title="SRv6 Locator TLV"> <name>SRv6 Locator TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="center" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Algorithm | Locator Length| PrefixOptions | | Route Type | Algorithm | Locator Length| PrefixOptions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator (up to 16 octets) ... | | Locator (up to 16 octets) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... | | ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator continued ... | | ... Locator continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... Locator concluded | | ... Locator concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) | | Sub-TLVs (variable) |
+- -+ +- -+
| ... | | ... |
]]></artwork> ]]></artwork>
</figure>Where:<list> </figure>
<t>Type: 2-octet field. The value for this type is 1.</t>
<t>Length: 2-octet field. The total length (in octets) of the
value portion of the TLV including nested Sub-TLVs.</t>
<t>Route Type: 1-octet field. The type of the locator route. The
only supported types are the ones listed below and the SRv6
Locator TLV MUST be ignored on receipt of any other type. <figure>
<artwork><![CDATA[
1 - Intra-Area
2 - Inter-Area
3 - AS External Type 1
4 - AS External Type 2
5 - NSSA External Type 1
6 - NSSA External Type 2
]]></artwork>
</figure></t>
<t>Algorithm: 1-octet field. The algorithm associated with the
SRv6 Locator. Algorithm values are defined in the IGP Algorithm
Type registry <xref target="RFC8665"/>.</t>
<t>Locator Length: 1-octet field. Specifies the length of the
Locator prefix as the number of locator bits from the range
(1-128).</t>
<t>PrefixOptions: 1-octet field. Specifies the prefix options
bits/flags as specified in <xref target="RFC5340"/> and further
extended by <xref target="RFC8362"/> and <xref target="ANYCAST"/>
of this document.</t>
<t>Metric: 4-octet field. The metric value associated with the
SRv6 Locator. The metric value of 0xFFFFFFFF MUST be considered as
unreachable.</t>
<t>Locator: Up to 16-octet field. This field encodes the
advertised SRv6 Locator as an IPv6 Prefix as specified in section
A.4.1 of <xref target="RFC5340"/>.</t>
<t>Sub-TLVs: Used to advertise Sub-TLVs that provide additional <t>where:</t>
<dl newline="false" spacing="normal">
<dt>Type:</dt><dd>2-octet field. The value for this type is 1.</dd>
<dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
value portion of the TLV, including nested sub-TLVs.</dd>
<dt>Route Type:</dt><dd><t>1-octet field. The type of the locator ro
ute. The
only supported types are the ones listed below, and the SRv6
Locator TLV <bcp14>MUST</bcp14> be ignored on receipt of any other t
ype.</t>
<dl newline="false" spacing="compact">
<dt>1:</dt><dd>Intra-Area</dd>
<dt>2:</dt><dd>Inter-Area</dd>
<dt>3:</dt><dd>AS External Type 1</dd>
<dt>4:</dt><dd>AS External Type 2</dd>
<dt>5:</dt><dd>NSSA External Type 1</dd>
<dt>6:</dt><dd>NSSA External Type 2</dd></dl>
</dd>
<dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with th
e
SRv6 Locator. Algorithm values are defined in the "IGP Algorithm
Types" registry <xref target="RFC8665" format="default"/>.</dd>
<dt>Locator Length:</dt><dd>1-octet field. Specifies the length of the
locator prefix as the number of locator bits from the range
(1-128).</dd>
<dt>PrefixOptions:</dt><dd>1-octet field. Specifies the prefix options
bits/flags as specified in <xref target="RFC5340" format="default"/>
and further
extended by <xref target="RFC8362" format="default"/> and <xref targ
et="ANYCAST" format="default"/>
of this document.</dd>
<dt>Metric:</dt><dd>4-octet field. The metric value associated with th
e
SRv6 Locator. The metric value of 0xFFFFFFFF <bcp14>MUST</bcp14> be
considered as
unreachable.</dd>
<dt>Locator:</dt><dd>1-16 octets. This field encodes the
advertised SRv6 Locator as an IPv6 Prefix as specified in <xref
target="RFC5340" sectionFormat="of" section="A.4.1"/>.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
al
attributes for the given SRv6 Locator and SRv6 SIDs associated attributes for the given SRv6 Locator and SRv6 SIDs associated
with the SRv6 Locator.</t> with the SRv6 Locator.</dd>
</list></t> </dl>
</section>
<section anchor="LOCSUBTLVS" title="SRv6 Locator Sub-TLVs"> </section>
<section anchor="LOCSUBTLVS" numbered="true" toc="default">
<name>SRv6 Locator Sub-TLVs</name>
<t>The following OSPFv3 Extended-LSA sub-TLVs corresponding to the <t>The following OSPFv3 Extended-LSA sub-TLVs corresponding to the
Extended Prefix LSAs are also applicable for use as sub-TLVs of the Extended Prefix LSAs are also applicable for use as sub-TLVs of the
SRv6 Locator TLV using code points as specified in <xref SRv6 Locator TLV using code points as specified in <xref target="IANALLS
target="IANALLSTLVS"/>:</t> TLVS" format="default"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>IPv6-Forwarding-Address sub-TLV <xref target="RFC8362" format="def
<t>IPv6-Forwarding-Address sub-TLV <xref target="RFC8362"/></t> ault"/></li>
<li>Route-Tag sub-TLV <xref target="RFC8362" format="default"/></li>
<t>Route-Tag sub-TLV <xref target="RFC8362"/></t> <li>Prefix Source OSPF Router-ID sub-TLV <xref target="RFC9084" format
="default"/></li>
<t>Prefix Source OSPF Router-ID sub-TLV <xref <li>Prefix Source Router Address sub-TLV <xref target="RFC9084" format
target="RFC9084"/></t> ="default"/></li>
</ul>
<t>Prefix Source Router Address sub-TLV <xref
target="RFC9084"/></t>
</list></t>
</section> </section>
</section> </section>
<section anchor="END" numbered="true" toc="default">
<section anchor="END" title="Advertisement of SRv6 End SIDs"> <name>Advertisement of SRv6 End SIDs</name>
<t>The SRv6 End SID Sub-TLV is a Sub-TLV of the SRv6 Locator TLV in the <t>The SRv6 End SID sub-TLV is a sub-TLV of the SRv6 Locator TLV in the
SRv6 Locator LSA (defined in <xref target="LOCLSA"/>). It is used to SRv6 Locator LSA (defined in <xref target="LOCLSA" format="default"/>). It
is used to
advertise the SRv6 SIDs belonging to the router along with their advertise the SRv6 SIDs belonging to the router along with their
associated endpoint behaviors. SIDs associated with adjacencies are associated Endpoint behaviors. SIDs associated with adjacencies are
advertised as described in <xref target="SRv6-Neighbor"/>. Every advertised as described in <xref target="SRv6-Neighbor" format="default"/>
SRv6-enabled OSPFv3 router SHOULD advertise at least one SRv6 SID . Every
associated with an END behavior for itself as specified in <xref SRv6-enabled OSPFv3 router <bcp14>SHOULD</bcp14> advertise at least one SR
target="RFC8986"/>, although it MAY omit doing so if that node is not v6 SID
going to be used as a Segment Endpoint (e.g., for TE or TI-LFA) by any associated with an End behavior for itself as specified in <xref target="R
FC8986" format="default"/>, although it <bcp14>MAY</bcp14> omit doing so if that
node is not
going to be used as a Segment Endpoint (e.g., for TE or Topology Independe
nt Loop-Free Alternate (TI-LFA)) by any
SR Source Node.</t> SR Source Node.</t>
<t>SRv6 End SIDs inherit the algorithm from the parent locator. The SRv6 <t>SRv6 End SIDs inherit the algorithm from the parent locator. The SRv6
End SID MUST be allocated from its associated locator. SRv6 End SIDs End SID <bcp14>MUST</bcp14> be allocated from its associated locator. SRv6
that are NOT allocated from the associated locator MUST be ignored.</t> End SIDs
that are NOT allocated from the associated locator <bcp14>MUST</bcp14> be
<t>The router MAY advertise multiple instances of the SRv6 End SID ignored.</t>
Sub-TLV within the SRv6 Locator TLV - one for each of the SRv6 SIDs to <t>The router <bcp14>MAY</bcp14> advertise multiple instances of the SRv6
be advertised. When multiple SRv6 End SID Sub-TLVs are received in the End SID
sub-TLV within the SRv6 Locator TLV -- one for each of the SRv6 SIDs to
be advertised. When multiple SRv6 End SID sub-TLVs are received in the
SRv6 Locator TLV from a given router for the same SRv6 SID value, the SRv6 Locator TLV from a given router for the same SRv6 SID value, the
receiver MUST use the first occurrence of the Sub-TLV in the SRv6 receiver <bcp14>MUST</bcp14> use the first occurrence of the sub-TLV in th e SRv6
Locator TLV.</t> Locator TLV.</t>
<t>The format of the SRv6 End SID sub-TLV is shown below</t>
<t>The format of SRv6 End SID Sub-TLV is shown below</t> <figure anchor="NODESIDTLV">
<name>SRv6 End SID Sub-TLV</name>
<figure anchor="NODESIDTLV" title="SRv6 End SID Sub-TLV"> <artwork name="" type="" align="center" alt=""><![CDATA[
<artwork><![CDATA[ 0 1 2 0 1 2 3
3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |
| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | Reserved | Endpoint Behavior |
| Flags | Reserved | Endpoint Behavior | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (128 bits) ... |
| SID (128 bits) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SID continued ... |
| ... SID continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SID continued ... |
| ... SID continued ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... SID concluded |
| ... SID concluded | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-TLVs (variable) . . .
| Sub-TLVs (variable) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>Where:<list> <t>where:</t>
<t>Type: 2-octet field. The value for this type is 1.</t> <dl>
<dt>Type:</dt><dd>2-octet field. The value for this type is 1.</dd>
<t>Length: 2-octet field. The total length (in octets) of the value <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the v
portion of the Sub-TLV including its further nested Sub-TLVs.</t> alue
portion of the sub-TLV, including its nested sub-TLVs.</dd>
<t>Flags: 1-octet field. It specifies the flags associated with the <dt>Flags:</dt><dd>1-octet field. Specifies the flags associated
SID. No flags are currently defined and this field MUST be set to 0 with the SID. No flags are currently defined, and this field
on transmission and MUST be ignored on receipt.</t> <bcp14>MUST</bcp14> be set to 0 on transmission and
<bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>Reserved: 1-octet field. It MUST be set to 0 on transmission and <dt>Reserved:</dt><dd>1-octet field. It <bcp14>MUST</bcp14> be set to 0
MUST be ignored on receipt.</t> on transmission and
<bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>Endpoint Behavior: 2 octets field. The endpoint behavior code <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint behavior code
point for this SRv6 SID as defined in <xref target="RFC8986"/>. point for this SRv6 SID as defined in <xref target="RFC8986" format="default"/>
Supported behavior values for this sub-TLV are defined in <xref .
target="AdvtEndBeh"/> of this document. Unsupported or unrecognized Supported behavior values for this sub-TLV are defined in <xref target
behavior values are ignored by the receiver.</t> ="AdvtEndBeh" format="default"/> of this document. Unsupported or unrecognized
behavior values are ignored by the receiver.</dd>
<t>SID: 16-octet field. This field encodes the advertised SRv6 <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv6
SID.</t> SID.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide additional
attributes for the given SRv6 SID.</dd>
</dl>
<t>Sub-TLVs: Used to advertise Sub-TLVs that provide additional
attributes for the given SRv6 SID.</t>
</list></t>
</section> </section>
<section anchor="SRv6-Neighbor" numbered="true" toc="default">
<section anchor="SRv6-Neighbor" <name>Advertisement of SRv6 SIDs Associated with Adjacencies</name>
title="Advertisement of SRv6 SIDs Associated with Adjacencies"> <t>The SRv6 Endpoint behaviors defined in <xref target="RFC8986" format="d
<t>The SRv6 endpoint behaviors defined in <xref target="RFC8986"/> efault"/>
include certain behaviors that are specific to links or adjacencies. The include certain behaviors that are specific to links or adjacencies. The
most basic of these, which is critical for link-state routing protocols most basic of these (which is critical for link-state routing protocols
like OSPFv3, is the End.X behavior that is an instruction to forward to like OSPFv3) is the End.X behavior, which is an instruction to forward to
a specific neighbor on a specific link. These SRv6 SIDs and others that a specific neighbor on a specific link. These SRv6 SIDs and others that
are defined in <xref target="RFC8986"/> which are specific to links or are defined in <xref target="RFC8986" format="default"/>, which are specif
adjacencies need to be advertised to OSPFv3 routers within an area to ic to links or
adjacencies, need to be advertised to OSPFv3 routers within an area to
steer SRv6 traffic over a specific link or adjacency.</t> steer SRv6 traffic over a specific link or adjacency.</t>
<t>Therefore, SRv6 SIDs that are specific to a particular neighbor, such <t>Therefore, SRv6 SIDs that are specific to a particular neighbor, such
as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV but as End.X, are not advertised as a sub-TLVs of the SRv6 Locator TLV. Instea
via two different optional Sub-TLVs of the E-Router-Link TLV defined in d, they are advertised via two different optional sub-TLVs of the E-Router-Link
<xref target="RFC8362"/>:</t> TLV defined in
<xref target="RFC8362" format="default"/>:</t>
<t><list style="symbols"> <dl>
<t>SRv6 End.X SID Sub-TLV: Used for OSPFv3 adjacencies over <dt>SRv6 End.X SID sub-TLV:</dt><dd>Used for OSPFv3 adjacencies over
point-to-point or point-to-multipoint links and for the adjacency to point-to-point or point-to-multipoint links and for the adjacency to
the Designated Router (DR) over broadcast and the Designated Router (DR) over broadcast and
Non-Broadcast-Multi-Access (NBMA) links.</t> Non-Broadcast-Multi-Access (NBMA) links.</dd>
<dt>SRv6 LAN End.X SID sub-TLV:</dt><dd>Used for OSPFv3 adjacencies on
<t>SRv6 LAN End.X SID Sub-TLV: Used for OSPFv3 adjacencies on
broadcast and NBMA links to the Backup DR and DR-Other neighbors. broadcast and NBMA links to the Backup DR and DR-Other neighbors.
This Sub-TLV includes the OSPFv3 Router-ID of the neighbor and thus This sub-TLV includes the OSPFv3 Router-ID of the neighbor and thus
allows for an instance of this Sub-TLV for each neighbor to be allows for an instance of this sub-TLV for each neighbor to be
explicitly advertised as a Sub-TLV of the E-Router-Link TLV for the explicitly advertised as a sub-TLV of the E-Router-Link TLV for the
same link.</t> same link.</dd>
</list>Every SRv6 enabled OSPFv3 router SHOULD instantiate at least </dl>
<t>Every SRv6-enabled OSPFv3 router <bcp14>SHOULD</bcp14> instantiate at l
east
one unique SRv6 End.X SID corresponding to each of its neighbors, one unique SRv6 End.X SID corresponding to each of its neighbors,
although it MAY omit doing so if features like traffic engineering or although it <bcp14>MAY</bcp14> omit doing so if features like TE or
Topology-Independent Loop Free Alternate (TI-LFA) that require End.X SID TI-LFA that require End.X SID
are not in use. A router MAY instantiate more than one SRv6 End.X SID are not in use. A router <bcp14>MAY</bcp14> instantiate more than one SRv6
for a single neighbor. The same SRv6 End.X SID MAY be advertised for End.X SID
more than one neighbor. Thus multiple instances of the SRv6 End.X SID for a single neighbor. The same SRv6 End.X SID <bcp14>MAY</bcp14> be adver
and SRv6 LAN End.X SID Sub-TLVs MAY be advertised within the tised for
more than one neighbor. Thus, multiple instances of the SRv6 End.X SID
and SRv6 LAN End.X SID sub-TLVs <bcp14>MAY</bcp14> be advertised within th
e
E-Router-Link TLV for a single link.</t> E-Router-Link TLV for a single link.</t>
<t>All End.X and LAN End.X SIDs <bcp14>MUST</bcp14> be subsumed by the sub
<t>All End.X and LAN End.X SIDs MUST be subsumed by the subnet of a net of a
Locator with the matching algorithm which is advertised by the same locator with the matching algorithm that is advertised by the same
OSPFv3 router in an SRv6 Locator TLV. End.X SIDs which do not meet this OSPFv3 router in an SRv6 Locator TLV. End.X SIDs that do not meet this
requirement MUST be ignored. This ensures that the OSPFv3 router requirement <bcp14>MUST</bcp14> be ignored. This ensures that the OSPFv3 r
outer
advertising the End.X or LAN End.X SID is also advertising its advertising the End.X or LAN End.X SID is also advertising its
corresponding Locator with the algorithm that will be used for computing corresponding locator with the algorithm that will be used for computing
paths destined to the SID.</t> paths destined to the SID.</t>
<section anchor="P2P" numbered="true" toc="default">
<section anchor="P2P" title="SRv6 End.X SID Sub-TLV"> <name>SRv6 End.X SID Sub-TLV</name>
<t>The format of the SRv6 End.X SID Sub-TLV is shown below</t> <t>The format of the SRv6 End.X SID sub-TLV is shown below:</t>
<figure anchor="ADJSIDTLV">
<figure anchor="ADJSIDTLV" title="SRv6 End.X SID Sub-TLV"> <name>SRv6 End.X SID Sub-TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="center" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 | | Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 | | Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... | | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded | | ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> </figure>
<t>Where:</t> <t>where:</t>
<dl newline="false">
<t><list> <dt>Type:</dt><dd>2-octet field. The value for this type is 31.</dd>
<t>Type: 2-octet field. The value for this type is 31.</t> <dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
value portion of the sub-TLV, including its nested
<t>Length: 2-octet field. The total length (in octets) of the sub-TLVs.</dd>
value portion of the Sub-TLV including its further nested <dt>Endpoint Behavior:</dt><dd>2-octet field. The Endpoint behavior co
Sub-TLVs.</t> de point for this SRv6 SID as defined in <xref target="RFC8986" format="default"
/>.
<t>Endpoint Behavior: 2-octet field. The endpoint behavior code Supported behavior values for this sub-TLV are defined in <xref targ
point for this SRv6 SID as defined in <xref target="RFC8986"/>. et="AdvtEndBeh" format="default"/> of this document. Unsupported or
Supported behavior values for this sub-TLV are defined in <xref unrecognized behavior values are ignored by the receiver.</dd>
target="AdvtEndBeh"/> of this document. Unsupported or <dt>Flags:</dt><dd><t> 1-octet field. The flags are defined as follows
unrecognized behavior values are ignored by the receiver.</t> :</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<t>Flags: 1-octet field. The flags are defined as follows: <figure> 0 1 2 3 4 5 6 7
<artwork><![CDATA[ +-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7 |B|S|P| Reserved|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <list style="symbols"> -+-+-+-+-+-+-+-+
<t>B-Flag: Backup Flag. If set, the SID refers to a path that <dl newline="false">
is eligible for protection.</t> <dt>B-Flag:</dt><dd>Backup Flag. If set, the SID refers to a path
that
<t>S-Flag: Set Flag. When set, the S-Flag indicates that the is eligible for protection.</dd>
End.X SID refers to a set of adjacencies (and therefore MAY be <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that
assigned to other adjacencies as well).</t> the
End.X SID refers to a set of adjacencies (and therefore <bcp14>M
<t>P-Flag: Persistent Flag: If set, the SID is persistently AY</bcp14> be
assigned to other adjacencies as well).</dd>
<dt>P-Flag:</dt><dd>Persistent Flag. If set, the SID is persistent
ly
allocated, i.e., the SID value remains consistent across allocated, i.e., the SID value remains consistent across
router restart and session/interface flap.</t> router restart and session/interface flap.</dd>
<dt>Other flags are not defined and are reserved for future
<t>Other flags are not defined and are reserved for future use. They <bcp14>MUST</bcp14> be set to 0 on transmission and <b
use. They MUST be set to 0 on transmission and MUST be ignored cp14>MUST</bcp14> be ignored
on receipt.</t> on receipt.</dt><dd></dd>
</list></t> </dl>
</dd>
<t>Reserved1: 1-octet field. It MUST be set to 0 on transmission </dl>
and MUST be ignored on receipt.</t> <dl>
<dt>Reserved1:</dt><dd>1-octet field. It <bcp14>MUST</bcp14> be set to
<t>Algorithm: 1-octet field. The algorithm associated with the 0 on transmission
and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with th
e
SRv6 Locator from which the SID is allocated. Algorithm values are SRv6 Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry <xref defined in the "IGP Algorithm Types" registry <xref target="RFC8665"
target="RFC8665"/>.</t> format="default"/>.</dd>
<dt>Weight:</dt><dd>1-octet field. Its value represents the weight of
<t>Weight: 1-octet field. Its value represents the weight of the the
End.X SID for load-balancing. The use of the weight is defined in End.X SID for load-balancing. The use of the weight is defined in
<xref target="RFC8402"/>.</t> <xref target="RFC8402" format="default"/>.</dd>
<dt>Reserved2:</dt><dd>2-octet field. It <bcp14>MUST</bcp14> be set to
<t>Reserved2: 2-octet field. It MUST be set to 0 on transmission 0 on transmission
and MUST be ignored on receipt.</t> and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv
<t>SID: 16-octet field. This field encodes the advertised SRv6 6
SID.</t> SID.</dd>
<dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
<t>Sub-TLVs: Used to advertise Sub-TLVs that provide additional al
attributes for the given SRv6 End.X SID.</t> attributes for the given SRv6 End.X SID.</dd>
</list></t> </dl>
</section> </section>
<section anchor="LAN" numbered="true" toc="default">
<section anchor="LAN" title="SRv6 LAN End.X SID Sub-TLV"> <name>SRv6 LAN End.X SID Sub-TLV</name>
<t>The format of the SRv6 LAN End.X SID Sub-TLV is as shown below:</t> <t>The format of the SRv6 LAN End.X SID sub-TLV is as shown below:</t>
<figure anchor="LADJSIDTLV">
<t><figure anchor="LADJSIDTLV" title="SRv6 LAN End.X SID Sub-TLV"> <name>SRv6 LAN End.X SID Sub-TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork name="" type="" align="center" alt=""><![CDATA[
3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Flags | Reserved1 | | Endpoint Behavior | Flags | Reserved1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Weight | Reserved2 | | Algorithm | Weight | Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router-ID | | Neighbor Router-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (128 bits) ... | | SID (128 bits) ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID continued ... | | ... SID continued ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... SID concluded | | ... SID concluded |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) . . . | Sub-TLVs (variable) . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:</t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t><list style="symbols">
<t>Type: 2-octet field. The value for this type is 32.</t>
<t>Length: 2-octet field. The total length (in octets) of the
value portion of the Sub-TLV including its further nested
Sub-TLVs.</t>
<t>Endpoint Behavior: 2-octet field. The code point for the
endpoint behavior for this SRv6 SID as defined in section 9.2 of
<xref target="RFC8986"/>.</t>
<t>Flags: 1-octet field. The flags are defined as follows:<figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
<t>where:</t>
<dl spacing="normal" newline="false">
<dt>Type:</dt><dd>2-octet field. The value for this type is 32.</dd>
<dt>Length:</dt><dd>2-octet field. The total length (in octets) of the
value portion of the sub-TLV, including its nested
sub-TLVs.</dd>
<dt>Endpoint Behavior:</dt><dd>2-octet field. The code point for the
Endpoint behavior for this SRv6 SID as defined in <xref
target="RFC8986" sectionFormat="of" section="9.2"/>.</dd>
<dt>Flags:</dt><dd><t>1-octet field. The flags are defined as follows:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|B|S|P| Reserved|
+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure><list style="symbols"> <dl spacing="normal" newline="false">
<t>B-Flag: Backup Flag. If set, the SID refers to a path that <dt>B-Flag:</dt><dd>Backup Flag. If set, the SID refers to a path
is eligible for protection.</t> that
is eligible for protection.</dd>
<t>S-Flag: Set Flag. When set, the S-Flag indicates that the <dt>S-Flag:</dt><dd>Set Flag. When set, the S-Flag indicates that
End.X SID refers to a set of adjacencies (and therefore MAY be the
assigned to other adjacencies as well).</t> End.X SID refers to a set of adjacencies (and therefore <bcp14>M
AY</bcp14> be
<t>P-Flag: Persistent Flag: If set, the SID is persistently assigned to other adjacencies as well).</dd>
<dt>P-Flag:</dt><dd>Persistent Flag. If set, the SID is persistent
ly
allocated, i.e., the SID value remains consistent across allocated, i.e., the SID value remains consistent across
router restart and session/interface flap.</t> router restart and session/interface flap.</dd>
<dt>Other flags are not defined and are reserved for future
<t>Other flags are not defined and are reserved for future use. They <bcp14>MUST</bcp14> be set to 0 on transmission and <b
use. They MUST be set to 0 on transmission and MUST be ignored cp14>MUST</bcp14> be ignored
on receipt.</t> on receipt.</dt><dd></dd>
</list></t> </dl>
</dd>
<t>Reserved1: 1-octet field. It MUST be set to 0 on transmission <dt>Reserved1:</dt><dd>1-octet field. It <bcp14>MUST</bcp14> be set to
and MUST be ignored on receipt.</t> 0 on transmission
and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>Algorithm: 1-octet field. The algorithm associated with the <dt>Algorithm:</dt><dd>1-octet field. The algorithm associated with th
e
SRv6 Locator from which the SID is allocated. Algorithm values are SRv6 Locator from which the SID is allocated. Algorithm values are
defined in the IGP Algorithm Type registry <xref defined in the "IGP Algorithm Types" registry <xref target="RFC8665"
target="RFC8665"/>.</t> format="default"/>.</dd>
<dt>Weight:</dt><dd>1-octet field. Its value represents the weight of
<t>Weight: 1-octet field. Its value represents the weight of the the
End.X SID for load balancing. The use of the weight is defined in End.X SID for load balancing. The use of the weight is defined in
<xref target="RFC8402"/>.</t> <xref target="RFC8402" format="default"/>.</dd>
<dt>Reserved2:</dt><dd>2-octet field. It <bcp14>MUST</bcp14> be set to
<t>Reserved2: 2-octet field. It MUST be set to 0 on transmission 0 on transmission
and MUST be ignored on receipt.</t> and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Neighbor Router-ID:</dt><dd>4-octet field. It specifies the OSPFv3
<t>Neighbor Router-ID: 4-octet field. It specifies the OSPFv3 Router-ID of the neighbor.</dd>
Router-id of the neighbor.</t> <dt>SID:</dt><dd>16-octet field. This field encodes the advertised SRv
6
<t>SID: 16-octet field. This field encodes the advertised SRv6 SID.</dd>
SID.</t> <dt>Sub-TLVs:</dt><dd>Used to advertise sub-TLVs that provide addition
al
<t>Sub-TLVs: Used to advertise Sub-TLVs that provide additional attributes for the given SRv6 SID.</dd>
attributes for the given SRv6 SID.</t> </dl>
</list></t>
</section> </section>
</section> </section>
<section anchor="SRSTRUCTTLV" numbered="true" toc="default">
<section anchor="SRSTRUCTTLV" title="SRv6 SID Structure Sub-TLV"> <name>SRv6 SID Structure Sub-TLV</name>
<t>SRv6 SID Structure Sub-TLV is used to advertise the structure of the <t>The SRv6 SID Structure sub-TLV is used to advertise the structure of th
SRv6 SID as defined in <xref target="RFC8986"/>. It is used as an e
optional Sub-TLV of the following:<list style="symbols"> SRv6 SID as defined in <xref target="RFC8986" format="default"/>. It is us
<t>SRv6 End SID Sub-TLV (refer to <xref target="END"/>)</t> ed as an
optional sub-TLV of the following:</t>
<t>SRv6 End.X SID Sub-TLV (refer to <xref target="P2P"/>)</t> <ul spacing="normal">
<li>SRv6 End SID sub-TLV (refer to <xref target="END" format="default"/>
<t>SRv6 LAN End.X SID Sub-TLV (refer to <xref target="LAN"/>)</t> )</li>
</list> The Sub-TLV has the following format:</t> <li>SRv6 End.X SID sub-TLV (refer to <xref target="P2P" format="default"
/>)</li>
<t><figure anchor="SRSIDSTRUCT" title="SRv6 SID Structure Sub-TLV"> <li>SRv6 LAN End.X SID sub-TLV (refer to <xref target="LAN" format="defa
<artwork><![CDATA[ 0 1 2 ult"/>)</li>
3 </ul>
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 <t>The sub-TLV has the following format:</t>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <figure anchor="SRSIDSTRUCT">
| Type | Length | <name>SRv6 SID Structure Sub-TLV</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <artwork name="" type="" align="center" alt=""><![CDATA[
| LB Length | LN Length | Fun. Length | Arg. Length | 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LB Length | LN Length | Fun. Length | Arg. Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type: 2-octet field. The value for this type is 30.</t> </figure>
<t>Length: 2-octet field. The value MUST be 4.</t>
<t>LB Length: 1-octet field. SRv6 SID Locator Block length in
bits.</t>
<t>LN Length: 1-octet bit field. SRv6 SID Locator Node length in
bits.</t>
<t>Function Length: 1-octet field. SRv6 SID Function length in
bits.</t>
<t>Argument Length: 1-octet field. SRv6 SID Argument length in
bits.</t>
</list></t>
<t>The SRv6 SID Structure Sub-TLV MUST NOT appear more than once in its
parent Sub-TLV. If it appears more than once in its parent Sub-TLV, the
parent Sub-TLV MUST be ignored by the receiver.</t>
<t>The sum of all four sizes advertised in SRv6 SID Structure Sub-TLV
MUST be less than or equal to 128 bits. If the sum of all four sizes
advertised in the SRv6 SID Structure Sub-TLV is larger than 128 bits,
the parent TLV/Sub-TLV MUST be ignored by the receiver.</t>
<t>The SRv6 SID Structure Sub-TLV is intended for informational use by <t>where:</t>
the control and management planes. It MUST NOT be used at a transit node <dl newline="false">
(as defined in <xref target="RFC8754"/>) for forwarding packets. As an <dt>Type:</dt><dd>2-octet field. The value for this type is 30.</dd>
example, this information could be used for: <list style="symbols"> <dt>Length:</dt><dd>2-octet field. The value <bcp14>MUST</bcp14> be 4.</
<t>validation of SRv6 SIDs being instantiated in the network and dd>
advertised via OSPFv3. These can be learned by controllers via <dt>LB Length:</dt><dd>1-octet field. SRv6 SID Locator Block length in
BGP-LS <xref target="I-D.ietf-idr-bgpls-srv6-ext"/> and then be bits.</dd>
monitored for conformance to the SRv6 SID allocation scheme chosen <dt>LN Length:</dt><dd>1-octet field. SRv6 SID Locator Node length in
by the operator as described in Section 3.2 of <xref bits.</dd>
target="RFC8986"/>.</t> <dt>Function Length:</dt><dd>1-octet field. SRv6 SID Function length in
bits.</dd>
<dt>Argument Length:</dt><dd>1-octet field. SRv6 SID Argument length in
bits.</dd>
</dl>
<t>verification and the automation for securing the SRv6 domain by <t>The SRv6 SID Structure sub-TLV <bcp14>MUST NOT</bcp14> appear more than
once in its
parent sub-TLV. If it appears more than once in its parent sub-TLV, the
parent sub-TLV <bcp14>MUST</bcp14> be ignored by the receiver.</t>
<t>The sum of all four sizes advertised in SRv6 SID Structure sub-TLV
<bcp14>MUST</bcp14> be less than or equal to 128 bits. If the sum of all f
our sizes
advertised in the SRv6 SID Structure sub-TLV is larger than 128 bits,
the parent TLV or sub-TLV <bcp14>MUST</bcp14> be ignored by the receiver.<
/t>
<t>The SRv6 SID Structure sub-TLV is intended for informational use by
the control and management planes. It <bcp14>MUST NOT</bcp14> be used at a
transit node
(as defined in <xref target="RFC8754" format="default"/>) for forwarding p
ackets. As an
example, this information could be used for the following: </t>
<ul spacing="normal">
<li>Validation of SRv6 SIDs being instantiated in the network and
advertised via OSPFv3. These can be learned by controllers via BGP-LS
<xref target="RFC9514" format="default"/> and then monitored for
conformance to the SRv6 SID allocation scheme chosen by the operator
as described in <xref target="RFC8986"
sectionFormat="of" section="3.2"/>.</li>
<li>Verification and the automation for securing the SRv6 domain by
provisioning filtering rules at SR domain boundaries as described in provisioning filtering rules at SR domain boundaries as described in
Section 5 of <xref target="RFC8754"/>.</t> <xref target="RFC8754" sectionFormat="of" section="5"/>.</li>
</list></t> </ul>
<t>The details of these potential applications are outside the scope of <t>The details of these potential applications are outside the scope of
this document.</t> this document.</t>
</section> </section>
<section anchor="AdvtEndBeh" numbered="true" toc="default">
<section anchor="AdvtEndBeh" title="Advertising Endpoint Behaviors"> <name>Advertising Endpoint Behaviors</name>
<t>Endpoint behaviors are defined in <xref target="RFC8986"/>. The <t>Endpoint behaviors are defined in <xref target="RFC8986" format="defaul
codepoints for the Endpoint behaviors are defined in the "SRv6 Endpoint t"/>. The
Behaviors" registry of <xref target="RFC8986"/>. This section lists the code points for the Endpoint behaviors are defined in the "SRv6 Endpoint
Endpoint behaviors and their codepoints, which MAY be advertised by Behaviors" registry of <xref target="RFC8986" format="default"/>. This sec
OSPFv3 and the Sub-TLVs in which each type MAY appear.</t> tion lists the
Endpoint behaviors and their code points, which <bcp14>MAY</bcp14> be adve
<t><figure anchor="EndBehTable" rtised by
title="SRv6 Endpoint Behaviors in OSPFv3"> OSPFv3 and the sub-TLVs in which each type <bcp14>MAY</bcp14> appear.</t>
<artwork><![CDATA[ <table anchor="EndBehTable">
|-----------------------|--------------------|-----|-------|-----------| <name>SRv6 Endpoint Behaviors in OSPFv3</name>
| Endpoint | Endpoint | End | End.X | LAN End.X | <thead>
| Behavior | Behavior Codepoint | SID | SID | SID | <tr>
|-----------------------|--------------------|-----|-------|-----------| <th>Endpoint Behavior</th>
| End (PSP, USP, USD) | 1-4, 28-31 | Y | N | N | <th>Endpoint Behavior Code Point</th>
|-----------------------|--------------------|-----|-------|-----------| <th>End SID</th>
| End.X (PSP, USP, USD) | 5-8, 32-35 | N | Y | Y | <th>End.X SID</th>
|-----------------------|--------------------|-----|-------|-----------| <th>LAN End.X SID</th>
| End.DX6 | 16 | N | Y | Y | </tr>
|-----------------------|--------------------|-----|-------|-----------| </thead>
| End.DX4 | 17 | N | Y | Y | <tbody>
|-----------------------|--------------------|-----|-------|-----------| <tr>
| End.DT6 | 18 | Y | N | N | <td>End (PSP, USP, USD)</td>
|-----------------------|--------------------|-----|-------|-----------| <td>1-4, 28-31</td>
| End.DT4 | 19 | Y | N | N | <td>Y</td>
|-----------------------|--------------------|-----|-------|-----------| <td>N</td>
| End.DT64 | 20 | Y | N | N | <td>N</td>
|-----------------------|--------------------|-----|-------|-----------| </tr>
<tr>
]]></artwork> <td>End.X (PSP, USP, USD)</td>
</figure></t> <td>5-8, 32-35</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>End.DX6</td>
<td>16</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>End.DX4</td>
<td>17</td>
<td>N</td>
<td>Y</td>
<td>Y</td>
</tr>
<tr>
<td>End.DT6</td>
<td>18</td>
<td>Y</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td>End.DT4</td>
<td>19</td>
<td>Y</td>
<td>N</td>
<td>N</td>
</tr>
<tr>
<td>End.DT64</td>
<td>20</td>
<td>Y</td>
<td>N</td>
<td>N</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document introduces extensions to the OSPFv3 protocol and as <t>This document introduces extensions to the OSPFv3 protocol and, as such
such does not affect existing security considerations for OSPFv3 as ,
documented in <xref target="RFC5340"/>. <xref target="RFC7166"/> does not affect existing security considerations for OSPFv3 as
documented in <xref target="RFC5340" format="default"/>. <xref target="RFC
7166" format="default"/>
describes an alternative and improved authentication mechanism to IPsec describes an alternative and improved authentication mechanism to IPsec
for OSPFv3. The use of authentication is RECOMMENDED for OSPFv3 for OSPFv3. The use of authentication is <bcp14>RECOMMENDED</bcp14> for OS PFv3
deployment.</t> deployment.</t>
<t>Reception of a malformed TLV or sub-TLV <bcp14>SHOULD</bcp14> be counte
<t>Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged d and/or logged
in a rate-limited manner for further analysis.</t> in a rate-limited manner for further analysis.</t>
<t>This document describes the OSPFv3 extensions required to support <t>This document describes the OSPFv3 extensions required to support
Segment Routing over an IPv6 data plane. The security considerations for SR over an IPv6 data plane. The security considerations for
Segment Routing are discussed in <xref target="RFC8402"/>. <xref SR are discussed in <xref target="RFC8402" format="default"/>. <xref targe
target="RFC8986"/> defines the SRv6 Network Programming concept and t="RFC8986" format="default"/> defines the SRv6 Network Programming concept and
specifies the main Segment Routing behaviors to enable the creation of specifies the main SR behaviors to enable the creation of
interoperable overlays; the security considerations from that document interoperable overlays. The security considerations from that document
apply too.</t> apply as well.</t>
<t>The advertisement of an incorrect MSD value may have negative <t>The advertisement of an incorrect MSD value may have negative
consequences, see <xref target="RFC8476"/> for additional consequences. See <xref target="RFC8476" format="default"/> for additional
considerations.</t> considerations.</t>
<t>Security concerns associated with the setting of the O-flag are <t>Security concerns associated with the setting of the O-flag are
described in <xref target="RFC9259"/>.</t> described in <xref target="RFC9259" format="default"/>.</t>
<t>Security concerns associated with the usage of Flexible Algorithms <t>Security concerns associated with the usage of Flexible Algorithms
are described in <xref target="RFC9350"/>.</t> are described in <xref target="RFC9350" format="default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests IANA to perform allocations from OSPF and <t>Per this document, IANA has made allocations in OSPF- and
OSPFv3 related registries as well as creating of new registries as OSPFv3-related registries and created new registries, as
follows.</t> detailed in the following subsections.</t>
<section anchor="IANARI" numbered="true" toc="default">
<section anchor="IANARI" title="OSPF Router Information TLVs"> <name>OSPF Router Information TLVs</name>
<t>IANA has allocated a code point via the early allocation process in <t>IANA has allocated the following code point in the "OSPF Router
the "OSPF Router Information (RI) TLVs" registry under the "OSPF Information (RI) TLVs" registry within the "Open Shortest Path First
Parameters" registry group for the new TLV below that needs to be made (OSPF) Parameters" registry group:</t>
permanent:</t> <table anchor="iana1">
<name></name>
<t><list style="empty"> <thead>
<t>Type 20: SRv6-Capabilities TLV: Refer to <xref <tr>
target="capability"/> of this document.</t> <th>Value</th>
</list></t> <th>TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>20</td>
<td>SRv6 Capabilities</td>
<td>RFC 9513, <xref target="capability"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANALSA" numbered="true" toc="default">
<section anchor="IANALSA" title="OSPFv3 LSA Function Codes"> <name>OSPFv3 LSA Function Codes</name>
<t>IANA has allocated a code point via the early allocation process in <t>IANA has allocated the following code point in
the "OSPFv3 LSA Function Codes" registry under the "OSPFv3 Parameters" the "OSPFv3 LSA Function Codes" registry within the "Open Shortest Path
registry group for the new LSA below that needs to be made First v3 (OSPFv3) Parameters"
permanent:</t> registry group:
</t>
<t><list style="symbols"> <table anchor="iana2">
<t>Type 42: SRv6 Locator LSA: Refer to <xref target="LOCLSA"/> of <name></name>
this document.</t> <thead>
</list></t> <tr>
<th>Value</th>
<th>LSA Function Code Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>42</td>
<td>SRv6 Locator LSA</td>
<td>RFC 9513, <xref target="LOCLSA"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANAPO" numbered="true" toc="default">
<section anchor="IANAPO" title="OSPFv3 Prefix Options"> <name>OSPFv3 Prefix Options</name>
<t>IANA has allocated a code point via the early allocation process in <t>IANA has allocated the following code point in the "OSPFv3 Prefix
the "OSPFv3 Prefix Options" registry under the "OSPFv3 Parameters" Options (8 bits)" registry within the "Open Shortest Path First v3
registry group as below that needs to be made permanent:</t> (OSPFv3) Parameters" registry group:</t>
<table anchor="iana3">
<t><list style="symbols"> <name></name>
<t>Value 0x80: AC-bit: Refer to <xref target="ANYCAST"/> of this <thead>
document.</t> <tr>
</list></t> <th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0x80</td>
<td>AC-bit</td>
<td>RFC 9513, <xref target="ANYCAST"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANASRV6CAP" numbered="true" toc="default">
<section anchor="IANASRV6CAP" title="OSPFv3 SRv6 Capabilities TLV Flags"> <name>OSPFv3 SRv6 Capabilities TLV Flags</name>
<t>This document requests a new IANA sub-registry name "OSPFv3 SRv6 <t>IANA has created a new subregistry named "OSPFv3 SRv6
Capabilities TLV Flags" be created under the "OSPFv3 Parameters" Capabilities TLV Flags" within the "Open Shortest Path First v3 (OSPFv3)
Parameters"
registry group to control the assignment of bits 0 to 15 in the Flags registry group to control the assignment of bits 0 to 15 in the Flags
field of the OSPFv3 SRv6 Capabilities TLV specified in this document. field of the OSPFv3 SRv6 Capabilities TLV specified in this document.
The registration procedure is "Standards Action" as defined in <xref The registration procedure is "Standards Action" as defined in <xref tar
target="RFC8126"/>.</t> get="RFC8126" format="default"/>.</t>
<t>The following assignment has been made per this document:</t>
<t>The following assignments are made by this document:<list <table anchor="iana4">
style="symbols"> <name></name>
<t>Bit 1: Description: O-flag. Reference: <xref <thead>
target="capability"/> of this document.</t> <tr>
</list></t> <th>Bit</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>O-flag</td>
<td>RFC 9513, <xref target="capability"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANASRV6END" numbered="true" toc="default">
<section anchor="IANASRV6END" title="OSPFv3 SRv6 End SID Sub-TLV Flags"> <name>OSPFv3 SRv6 End SID Sub-TLV Flags</name>
<t>This document requests a new IANA sub-registry name "OSPFv3 SRv6 <t>IANA has created a new subregistry named "OSPFv3 SRv6
End SID Sub-TLV Flags" be created under the "OSPFv3 Parameters" End SID Sub-TLV Flags" within the "Open Shortest Path First v3 (OSPFv3)
Parameters"
registry group to control the assignment of bits 0 to 7 in the Flags registry group to control the assignment of bits 0 to 7 in the Flags
field of the OSPFv3 SRv6 End SID Sub-TLV specified in this document. field of the OSPFv3 SRv6 End SID sub-TLV specified in this document.
The registration procedure is "Standards Action" as defined in <xref The registration procedure is "Standards Action" as defined in <xref tar
target="RFC8126"/>.</t> get="RFC8126" format="default"/>.</t>
<t>No assignments are made by this document.</t> <t>No assignments are made by this document.</t>
</section> </section>
<section anchor="IANASRV6ENDX" numbered="true" toc="default">
<section anchor="IANASRV6ENDX" <name>OSPFv3 SRv6 Adjacency SID Sub-TLV Flags</name>
title="OSPFv3 SRv6 Adjacency SID Sub-TLV Flags"> <t>IANA has created a new subregistry named "OSPFv3 SRv6
<t>This document requests a new IANA sub-registry name "OSPFv3 SRv6 Adjacency SID Sub-TLV Flags" within the "Open Shortest Path First v3 (OS
Adjacency SID Sub-TLV Flags" be created under the "OSPFv3 Parameters" PFv3) Parameters"
registry group to control the assignment of bits 0 to 7 in the Flags registry group to control the assignment of bits 0 to 7 in the Flags
field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID field of the OSPFv3 SRv6 End.X SID and OSPFv3 SRv6 LAN End.X SID
Sub-TLVs specified in this document. The registration procedure is sub-TLVs specified in this document. The registration procedure is
"Standards Action" as defined in <xref target="RFC8126"/>.</t> "Standards Action" as defined in <xref target="RFC8126" format="default"
/>.</t>
<t>The following assignments are made by this document:<list <t>The following assignments have been made per this document:</t>
style="symbols"> <table anchor="iana5">
<t>Bit 0: Description: B-flag. Reference: <xref target="P2P"/> and <name></name>
<xref target="LAN"/> of this document.</t> <thead>
<tr>
<t>Bit 1: Description: S-flag. Reference: <xref target="P2P"/> and <th>Bit</th>
<xref target="LAN"/> of this document.</t> <th>Description</th>
<th>Reference</th>
<t>Bit 2: Description: P-flag. Reference: <xref target="P2P"/> and </tr>
<xref target="LAN"/> of this document.</t> </thead>
</list></t> <tbody>
<tr>
<td>0</td>
<td>B-flag</td>
<td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref tar
get="LAN" format="counter"/></td>
</tr>
<tr>
<td>1</td>
<td>S-flag</td>
<td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref tar
get="LAN" format="counter"/></td>
</tr>
<tr>
<td>2</td>
<td>P-flag</td>
<td>RFC 9513, Sections <xref target="P2P" format="counter"/> and <xref tar
get="LAN" format="counter"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANAELSTLVS" numbered="true" toc="default">
<section anchor="IANAELSTLVS" title="OSPFv3 Extended-LSA Sub-TLVs"> <name>OSPFv3 Extended-LSA Sub-TLVs</name>
<t>IANA has allocated the following code points via the early <t>IANA has allocated the following code points
allocation process in the "OSPFv3 Extended-LSA Sub-TLVs" registry in the "OSPFv3 Extended-LSA Sub-TLVs" registry
under the "OSPFv3 Parameters" registry group for the new Sub-TLVs within the "Open Shortest Path First v3 (OSPFv3) Parameters" registry gr
below that need to be made permanent:</t> oup:</t>
<table anchor="iana6">
<t><list style="symbols"> <name></name>
<t>Type 30: SRv6 SID Structure Sub-TLV: Refer to <xref <thead>
target="SRSTRUCTTLV"/> of this document.</t> <tr>
<th>Value</th>
<t>Type 31: SRv6 End.X SID Sub-TLV: Refer to <xref target="P2P"/> <th>Description</th>
of this document.</t> <th>L2BM</th>
<th>Reference</th>
<t>Type 32: SRv6 LAN End.X SID Sub-TLV: Refer to <xref </tr>
target="LAN"/> of this document.</t> </thead>
</list></t> <tbody>
<tr>
<t>For all 3 of these sub-TLVs the column L2BM in the registry is set <td>30</td>
to "Y".</t> <td>SRv6 SID Structure</td>
<td>Y</td>
<td>RFC 9513, <xref target="SRSTRUCTTLV"/></td>
</tr>
<tr>
<td>31</td>
<td>SRv6 End.X SID</td>
<td>Y</td>
<td>RFC 9513, <xref target="P2P"/></td>
</tr>
<tr>
<td>32</td>
<td>SRv6 LAN End.X SID</td>
<td>Y</td>
<td>RFC 9513, <xref target="LAN"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="IANALLTLVS" numbered="true" toc="default">
<section anchor="IANALLTLVS" title="OSPFv3 SRv6 Locator LSA TLVs"> <name>OSPFv3 SRv6 Locator LSA TLVs</name>
<t>This document requests the creation of an "OSPFv3 SRv6 Locator LSA <t>IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
TLVs" registry, that defines top-level TLVs for the OSPFv3 SRv6 TLVs" within the "Open Shortest Path First v3 (OSPFv3) Parameters" regis
Locator LSA, under the "OSPFv3 Parameters" registry group. The initial try group to define top-level TLVs for the OSPFv3 SRv6
code-points assignment is as below:</t> Locator LSA. The initial
assignments are below:</t>
<t><list style="symbols"> <table anchor="iana7">
<t>Type 0: Reserved.</t> <name></name>
<thead>
<t>Type 1: SRv6 Locator TLV: Refer to <xref target="LOCTLV"/> of <tr>
this document.</t> <th>Value</th>
</list></t> <th>Description</th>
<th>Reference</th>
<t>Types in the range 2-32767 are allocated via IETF Review or IESG </tr>
Approval <xref target="RFC8126"/>.</t> </thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9513</td>
</tr>
<tr>
<td>1</td>
<td>SRv6 Locator</td>
<td>RFC 9513, <xref target="LOCTLV"/></td>
</tr>
</tbody>
</table>
<t>Types in the range 0-32767 are allocated via IETF Review or IESG
Approval <xref target="RFC8126" format="default"/>.</t>
<t>Types in the range 32768-33023 are Reserved for Experimental Use; <t>Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by these will not be registered with IANA and <bcp14>MUST NOT</bcp14> be me ntioned by
RFCs.</t> RFCs.</t>
<t>Types in the range 33024-45055 are to be assigned on a First Come <t>Types in the range 33024-45055 are to be assigned on a First Come
First Served (FCFS) basis.</t> First Served (FCFS) basis.</t>
<t>Types in the range 45056-65535 are not to be assigned at this time. <t>Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 45056-65535 range, there Before any assignments can be made in the 45056-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that <bcp14>MUST</bcp14> be an IETF specification that specifies IANA Conside rations that
cover the range being assigned.</t> cover the range being assigned.</t>
</section> </section>
<section anchor="IANALLSTLVS" numbered="true" toc="default">
<name>OSPFv3 SRv6 Locator LSA Sub-TLVs</name>
<t>IANA has created a new subregistry named "OSPFv3 SRv6 Locator LSA
Sub-TLVs" within the "Open Shortest Path First v3 (OSPFv3) Parameters" r
egistry
group to define sub-TLVs at any level of nesting for
the SRv6 Locator LSA TLV.
The initial assignment are below:</t>
<table anchor="iana8">
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td>RFC 9513</td>
</tr>
<tr>
<td>1</td>
<td>SRv6 End SID</td>
<td>RFC 9513, <xref target="END"/></td>
</tr>
<tr>
<td>2</td>
<td>IPv6-Forwarding-Address</td>
<td><xref target="RFC8362"
format="default"/>; RFC 9513, <xref target="LOCSUBTLVS"/></td>
</tr>
<tr>
<td>3</td>
<td>Route-Tag</td>
<td><xref target="RFC8362" format="default"/>; RFC 9513, <xref target="LOC
SUBTLVS"/></td>
</tr>
<tr>
<td>4</td>
<td>Prefix Source OSPF Router-ID</td>
<td><xref target="RFC9084" format="default"/>; RFC 9513, <xref target="LOC
SUBTLVS"/></td>
</tr>
<tr>
<td>5</td>
<td>Prefix Source Router Address</td>
<td><xref target="RFC9084" format="default"/>; RFC 9513, <xref target="LOC
SUBTLVS"/></td>
</tr>
<tr>
<td>10</td>
<td>SRv6 SID Structure</td>
<td>RFC 9513, <xref target="SRSTRUCTTLV"/></td>
</tr> </tbody>
<section anchor="IANALLSTLVS" title="OSPFv3 SRv6 Locator LSA Sub-TLVs"> </table>
<t>This document requests the creation of an "OSPFv3 SRv6 Locator LSA <t>Types in the range 0-32767 are allocated via IETF Review
Sub-TLVs" registry, that defines Sub-TLVs at any level of nesting for or IESG Approval <xref target="RFC8126" format="default"/>.</t>
the SRv6 Locator LSA, to be added under the "OSPFv3 Parameters"
registry group. The initial code-points assignment is as below:</t>
<t><list style="symbols">
<t>Type 0: Reserved.</t>
<t>Type 1: SRv6 End SID Sub-TLV: Refer to <xref target="END"/> of
this document.</t>
<t>Type 2: IPv6-Forwarding-Address sub-TLV: Refer to <xref
target="RFC8362"/> and <xref target="LOCSUBTLVS"/> of this
document.</t>
<t>Type 3: Route-Tag sub-TLV: Refer to <xref target="RFC8362"/>
and <xref target="LOCSUBTLVS"/> of this document.</t>
<t>Type 4: Prefix Source OSPF Router-ID sub-TLV: Refer to <xref
target="RFC9084"/> and <xref target="LOCSUBTLVS"/> of this
document.</t>
<t>Type 5: Prefix Source Router Address sub-TLV: Refer to <xref
target="RFC9084"/> and <xref target="LOCSUBTLVS"/> of this
document.</t>
<t>Type 10: SRv6 SID Structure Sub-TLV: Refer to <xref
target="SRSTRUCTTLV"/> of this document.</t>
</list></t>
<t>Types in the range 6-9 and 11-32767 are allocated via IETF Review
or IESG Approval <xref target="RFC8126"/>.</t>
<t>Types in the range 32768-33023 are Reserved for Experimental Use; <t>Types in the range 32768-33023 are Reserved for Experimental Use;
these will not be registered with IANA and MUST NOT be mentioned by these will not be registered with IANA and <bcp14>MUST NOT</bcp14> be me ntioned by
RFCs.</t> RFCs.</t>
<t>Types in the range 33024-45055 are to be assigned on a FCFS basis.</t
<t>Types in the range 33024-45055 are to be assigned on a First Come >
First Served (FCFS) basis.</t>
<t>Types in the range 45056-65535 are not to be assigned at this time. <t>Types in the range 45056-65535 are not to be assigned at this time.
Before any assignments can be made in the 45056-65535 range, there Before any assignments can be made in the 45056-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that <bcp14>MUST</bcp14> be an IETF specification that specifies IANA Conside rations that
cover the range being assigned.</t> cover the range being assigned.</t>
<t>The following note has been added to this registry to
<t>The note indicated below needs to be added under this registry to ensure that any document requesting allocations in this registry
ensure that any document requesting allocations under this registry
for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs checks if for sub-TLVs of any of the OSPFv3 SRv6 Locator TLVs checks if
allocations are also applicable for the "OSPFv3 Extended-LSA Sub-TLVs" allocations are also applicable for the "OSPFv3 Extended-LSA Sub-TLVs"
registry.</t> registry.</t>
<t>Note: Allocations made under this registry for any sub-TLVs that <blockquote>
are associated with OSPFv3 SRv6 Locator TLVs MUST be also evaluated <t>Note: Allocations made in this registry for sub-TLVs that
for their applicability as OSPFv3 Extended-LSA Sub-TLVs and, are associated with OSPFv3 SRv6 Locator TLVs <bcp14>MUST</bcp14> be
therefore, also requiring allocation under the "OSPFv3 Extended-LSA evaluated for their applicability as OSPFv3 Extended-LSA sub-TLVs,
which are required to be allocated in the "OSPFv3 Extended-LSA
Sub-TLVs" registry.</t> Sub-TLVs" registry.</t>
</blockquote>
</section> </section>
<section anchor="IANAOSPFV3EXTLSA" numbered="true" toc="default">
<section anchor="IANAOSPFV3EXTLSA" title="OSPFv3 Extended-LSA Sub-TLVs"> <name>OSPFv3 Extended-LSA Sub-TLVs</name>
<t>This document requests IANA to add the note indicated below under <t>IANA has added the following note to
the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "OSPFv3 the "OSPFv3 Extended-LSA Sub-TLVs" registry within the "Open Shortest Pa
Parameters" registry group. The purpose of this note is to ensure that th First v3 (OSPFv3) Parameters" registry group. The purpose of this note is to
any document requesting allocations under this registry for sub-TLVs ensure that
any document requesting allocations in this registry for sub-TLVs
of any of the OSPFv3 Extended Prefix TLVs checks if allocations are of any of the OSPFv3 Extended Prefix TLVs checks if allocations are
also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry also applicable for the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry
that is created by this document.</t> defined in this document.</t>
<blockquote>
<t>Note: Allocations made under this registry for any sub-TLVs that <t>Note: Allocations made in this registry for sub-TLVs that
are associated with OSPFv3 Extended TLVs related to prefix are associated with OSPFv3 Extended TLVs related to prefix
advertisements MUST be also evaluated for their applicability as advertisements <bcp14>MUST</bcp14> be evaluated for their
OSPFv3 SRv6 Locator Sub-TLVs and, therefore, also requiring allocation applicability as OSPFv3 SRv6 Locator sub-TLVs, which are
under the "OSPFv3 SRv6 Locator LSA Sub-TLVs" registry.</t> required to be allocated in the "OSPFv3 SRv6 Locator LSA Sub-TLVs"
registry.</t>
</blockquote>
</section> </section>
</section> </section>
<section title="Acknowledgements">
<t>The authors would like to acknowledge the contributions of Dean Cheng
in the early versions of this document. The authors would like to thank
Ran Chen and Detao Zhao for their suggestions related to the extension
of PrefixOptions for the signaling of the anycast property.</t>
<t>The authors would like to thank Chenzichao, Dirk Goethals, Baalajee
S, Yingzhen Qu, Shraddha Hegde, Dhruv Dhody, Martin Vigoureux, and Reese
Enghardt for their review and comments on this document. The authors
would like to thank Acee Lindem for his detailed shepherd review and
feedback for improvement of this document. The authors would like to
thank John Scudder for his AD review and suggestions to improve this
document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.2119'?> <name>References</name>
<references>
<?rfc include='reference.RFC.8126'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.8174'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.5340'?> 126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.7166'?> 174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.7770'?> 340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8362'?> 166.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<?rfc include='reference.RFC.8402'?> 770.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8986'?> 362.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.9259'?> 402.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8666'?> 986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<?rfc include='reference.RFC.8665'?> 259.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8476'?> 666.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.8754'?> 665.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<?rfc include='reference.RFC.9084'?> 476.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
754.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
084.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
350.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
352.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
630.xml"/>
<?rfc include='reference.RFC.9350'?> <!-- [I-D.ietf-idr-bgpls-srv6-ext] in REF state as of 09/20/23; companion docume nt RFC 9514 -->
<?rfc include='reference.RFC.9352'?> <reference anchor="RFC9514" target="https://www.rfc-editor.org/info/rfc9514">
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Rout
ing over IPv6 (SRv6)</title>
<author initials="G." surname="Dawra" fullname="Gaurav Dawra">
<organization>LinkedIn</organization>
</author>
<author initials="C." surname="Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
</author>
<author initials="K." surname="Talaulikar" fullname="Ketan Talaulikar" role="edi
tor">
<organization>Cisco Systems</organization>
</author>
<author initials="M." surname="Chen" fullname="Mach Chen">
<organization>Huawei</organization>
</author>
<author initials="D." surname="Bernier" fullname="Daniel Bernier">
<organization>Bell Canada</organization>
</author>
<author initials="B." surname="Decraene" fullname="Bruno Decraene">
<organization>Orange</organization>
</author>
<date month="November" year="2023"/>
</front>
<seriesInfo name="RFC" value="9514"/>
<seriesInfo name="DOI" value="10.17487/RFC9514"/>
</reference>
</references>
</references> </references>
<references title="Informative References"> <section numbered="false" toc="default">
<?rfc include='reference.RFC.3630'?> <name>Acknowledgements</name>
<t>The authors would like to acknowledge the contributions of <contact ful
<?rfc include='reference.I-D.ietf-idr-bgpls-srv6-ext'?> lname="Dean Cheng"/>
</references> in the early draft versions of this document. The authors would like to th
</back> ank
<contact fullname="Ran Chen"/> and <contact fullname="Detao Zhao"/> for th
eir suggestions related to the extension
of PrefixOptions for the signaling of the anycast property.</t>
<t>The authors would like to thank <contact fullname="Chenzichao"/>,
<contact fullname="Dirk Goethals"/>, <contact fullname="Baalajee S"/>,
<contact fullname="Yingzhen Qu"/>, <contact fullname="Shraddha Hegde"/>,
<contact fullname="Dhruv Dhody"/>, <contact fullname="Martin
Vigoureux"/>, and <contact fullname="Reese Enghardt"/> for their review
and comments on this document. The authors would like to thank <contact
fullname="Acee Lindem"/> for his detailed shepherd review and feedback
for improvement of this document. The authors would like to thank
<contact fullname="John Scudder"/> for his AD review and suggestions to
improve this document.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 191 change blocks. 
1059 lines changed or deleted 1246 lines changed or added

This html diff was produced by rfcdiff 1.48.