rfc9502xml2.original.xml   rfc9502.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?> <!DOCTYPE rfc [
<?rfc tocdepth="3"?> <!ENTITY nbsp "&#160;">
<?rfc tocindent="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc symrefs="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc sortrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc comments="yes"?> ]>
<?rfc inline="yes"?>
<?rfc compact="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
<?rfc subcompact="no"?> std" consensus="true" docName="draft-ietf-lsr-ip-flexalgo-16" number="9502" ipr=
<rfc category="std" docName="draft-ietf-lsr-ip-flexalgo-16" ipr="trust200902"> "trust200902" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" upda
<front> tes="" obsoletes="" xml:lang="en" version="3">
<title abbrev="IP Flex-Algorithm">IGP Flexible Algorithms (Flex-Algorithm)
In IP Networks</title>
<front>
<title abbrev="IGP IP Flexible Algorithm">IGP Flexible Algorithm in IP
Networks</title>
<seriesInfo name="RFC" value="9502"/>
<author fullname="William Britto" initials="W." surname="Britto"> <author fullname="William Britto" initials="W." surname="Britto">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>Elnath-Exora Business Park Survey</street> <street>Elnath-Exora Business Park Survey</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>bwilliam@juniper.net</email> <email>bwilliam@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Shraddha Hegde" initials="S." surname="Hegde"> <author fullname="Shraddha Hegde" initials="S." surname="Hegde">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>Elnath-Exora Business Park Survey</street> <street>Elnath-Exora Business Park Survey</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>shraddha@juniper.net</email> <email>shraddha@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Parag Kaneriya " initials="P." surname="Kaneriya"> <author fullname="Parag Kaneriya " initials="P." surname="Kaneriya">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>Elnath-Exora Business Park Survey</street> <street>Elnath-Exora Business Park Survey</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>pkaneria@juniper.net</email> <email>pkaneria@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Rejesh Shetty" initials="R." surname="Shetty"> <author fullname="Rejesh Shetty" initials="R." surname="Shetty">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>Elnath-Exora Business Park Survey</street> <street>Elnath-Exora Business Park Survey</street>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560103</code> <code>560103</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>mrajesh@juniper.net</email> <email>mrajesh@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Ron Bonica" initials="R." surname="Bonica"> <author fullname="Ron Bonica" initials="R." surname="Bonica">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<postal> <postal>
<street>2251 Corporate Park Drive</street> <street>2251 Corporate Park Drive</street>
<city>Herndon</city> <city>Herndon</city>
<code>20171</code> <code>20171</code>
<region>Virginia</region> <region>Virginia</region>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>rbonica@juniper.net</email> <email>rbonica@juniper.net</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>Apollo Business Center</street> <extaddr>Apollo Business Center</extaddr>
<street>Mlynske nivy 43</street> <street>Mlynske nivy 43</street>
<city>Bratislava</city> <city>Bratislava</city>
<code>82109</code> <code>82109</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/> <area>rtg</area>
<workgroup>lsr</workgroup>
<area>Routing Area</area>
<workgroup>LSR Working Group</workgroup>
<keyword>IS-IS</keyword> <keyword>IS-IS</keyword>
<keyword>Draft</keyword>
<abstract> <abstract>
<t>This document extends IGP Flexible Algorithm so that it can be used wit
<t>This document extends IGP Flex-Algorithm, so that it can be used with h
regular IPv4 and IPv6 forwarding.</t> regular IPv4 and IPv6 forwarding.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section>
<name>Introduction</name>
<t>An IGP Flexible Algorithm (Flex-Algorithm) allows IGPs to compute <t>An IGP Flexible Algorithm allows IGPs to compute
constraint-based paths. The base IGP Flex-Algorithm specification constraint-based paths. The base IGP Flexible Algorithm specification
describes how it is used with Segment Routing (SR) data planes - SR MPLS a describes how it is used with Segment Routing (SR) data planes: SR MPLS an
nd d
SRv6.</t> SRv6.</t>
<t>An IGP Flexible Algorithm as specified in <xref target="RFC9350"/>
<t>An IGP Flex-Algorithm as specified in <xref computes a constraint-based path to:
target="RFC9350"/> computes a constraint-based path to: </t>
<list style="symbols"> <ul spacing="normal">
<t>All Flex-Algorithm specific Prefix Segment Identifiers (SIDs) <li>All Flexible-Algorithm-specific Prefix Segment Identifiers (SIDs)
<xref target="RFC8402"/>.</t> <xref target="RFC8402"/>.</li>
<li>All Flexible-Algorithm-specific SRv6 Locators <xref
<t>All Flex-Algorithm specific SRv6 Locators <xref target="RFC8986"/>.</li>
target="RFC8986"/>.</t> </ul>
</list>Therefore, Flex-Algorithm cannot be deployed in the absence of <t>Therefore, Flexible Algorithm cannot be deployed in the absence of
SR or SRv6.</t> SR or SRv6.</t>
<t>This document extends Flexible Algorithm, allowing it to compute paths
<t>This document extends Flex-Algorithm, allowing it to compute paths
to IPv4 and IPv6 prefixes.</t> to IPv4 and IPv6 prefixes.</t>
</section> </section>
<section anchor="ReqLang">
<section anchor="ReqLang" title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in <xref NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
target="RFC2119">BCP 14</xref> <xref target="RFC8174"/> when, and only "<bcp14>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 title="Use Case Example"> <name>Use Case Example</name>
<t>In this section, we illustrate one use case that motivates this
<t>In this subsection, we illustrate one use case that motivates this
specification: if a specific service can be identified by an IP specification: if a specific service can be identified by an IP
address, traffic to it can use constraint-based paths computed address, traffic to it can use constraint-based paths computed
according to this specification.</t> according to this specification.</t>
<t> The System architecture for the 5G System <xref
<t> The System Architecture for the 5G System <xref target="TS.23.501-3GPP target="TS.23.501-3GPP"/> describes the N3 interface between gNodeB and
"/> UPF (User Plane Function).</t>
describes the N3 interface between gNodeB and UPF (User Plane Function) <t>Mobile networks are becoming more and more IP-centric. Each end-user
.</t> session from a gNodeB can be destined to a specific UPF based on the
session requirements. For example, some sessions require high bandwidth,
<t>Mobile networks are becoming more and more IP centric. Each end-user while others need to be routed along the lowest latency path. Each UPF is
session from assigned a unique IP address. As a result, traffic for different
a gNodeB can be destined to a specific UPFs (User Plane Function) based on sessions is destined to a different destination IP address.</t>
the <t>The IP address allocated to the UPF can be associated with an
session requirements. For example, some sessions require high bandwidth, o algorithm. The mobile user traffic is then forwarded along the path
thers based on the algorithm-specific metric and constraints. As a result,
need to be routed along the lowest latency path. Each UPF is assigned a un traffic can be sent over a path that is optimized for minimal latency or
ique highest bandwidth. This mechanism is used to achieve Service Level
IP address. As a result, traffic for different sessions is destined to a d Agreement (SLA) appropriate for a user session.</t>
ifferent
destination IP address.</t>
<t>The IP address allocated to the UPF can be associated with an algorithm
. The mobile
user traffic is then forwarded along the path based on the algorithm-speci
fic
metric and constraints. As a result, traffic can be sent over a path that
is optimized
for minimal latency or highest bandwidth. This mechanism is used to achiev
e SLA
(Service Level Agreement) appropriate for a user session.</t>
</section> </section>
<section>
<section title="Advertising Flex-Algorithm Definitions (FAD)"> <name>Advertising Flexible Algorithm Definitions (FADs)</name>
<t>To guarantee loop-free forwarding, all routers that participate in a <t>To guarantee loop-free forwarding, all routers that participate in a
Flex-Algorithm MUST agree on the Flex-Algorithm Definition (FAD).</t> Flex-Algorithm <bcp14>MUST</bcp14> agree on the Flexible Algorithm Definit
ion (FAD).</t>
<t>Selected nodes within the IGP domain MUST advertise FADs as described <t>Selected nodes within the IGP domain <bcp14>MUST</bcp14> advertise
in Sections 5, 6, and 7 of <xref target="RFC9350"/>.</t> FADs as described in Sections <xref target="RFC9350" section="5"
sectionFormat="bare"/>, <xref target="RFC9350" section="6"
sectionFormat="bare"/>, and <xref target="RFC9350" section="7"
sectionFormat="bare"/> of <xref target="RFC9350"/>.</t>
</section> </section>
<section anchor="PARTICIPATION">
<section anchor="PARTICIPATION" <name>Advertising IP Flexible Algorithm Participation</name>
title="Advertising IP Flex-Algorithm Participation">
<t>A node may use various algorithms when calculating paths to nodes and <t>A node may use various algorithms when calculating paths to nodes and
prefixes. Algorithm values are defined in the <xref prefixes. Algorithm values are defined in the <xref target="IANA-ALG">"IGP
target="IANA-ALG">IGP Algorithm Type Registry </xref>.</t> Algorithm Types" registry </xref>.</t>
<t>Only a node that is participating in a Flex-Algorithm is:</t> <t>Only a node that is participating in a Flex-Algorithm is:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Able to compute a path for such Flex-Algorithm</li>
<t>Able to compute a path for such Flex-Algorithm</t> <li>Part of the topology for such Flex-Algorithm</li>
</ul>
<t>Part of the topology for such Flex-Algorithm</t> <t>Flexible Algorithm participation <bcp14>MUST</bcp14> be advertised for
</list></t> each Flexible Algorithm data plane independently, as specified in <xref
target="RFC9350"/>. Using Flexible Algorithm for regular IPv4 and IPv6
<t>Flex-Algorithm participation MUST be advertised for each prefixes represents an independent Flexible Algorithm data plane; as
Flex-Algorithm data-plane independently, as specified in such, the Flexible Algorithm participation for the IP Flexible Algorithm
<xref target="RFC9350"/>. Using Flex-Algorithm for data plane <bcp14>MUST</bcp14> be signaled independently of any other
regular IPv4 and IPv6 prefixes represents an independent Flex-Algorithm Flexible Algorithm data plane (e.g., SR).</t>
data-plane, and as such, the Flex-Algorithm participation for the IP Flex-
Algorithm
data-plane MUST be signalled independently of any other Flex-Algorithm
data-plane (e.g., SR).</t>
<t>All routers in an IGP domain participate in default algorithm 0. <t>All routers in an IGP domain participate in default algorithm 0.
Advertisement of participation in IP Flex-Algorithm does not impact Advertisement of participation in IP Flexible Algorithm does not impact
the router participation in default algorithm 0. the router participation in default algorithm 0.
</t> </t>
<t>Advertisement of participation in IP Flexible Algorithm does not impact
<t>Advertisement of participation in IP Flex-Algorithm does not impact the router participation signaled for other data planes. For example,
the router participation signaled for other data-planes. For example, it is possible that a router participates in a particular Flex-Algorith
it is possible that a router participates in a particular flex-algo m
for the IP data-plane but does not participate in the for the IP data plane but does not participate in the
same flex-algo for the SR data-plane.</t> same Flex-Algorithm for the SR data plane.</t>
<t>The following sections describe how the IP Flexible Algorithm participa
<t>The following sections describe how the IP Flex-Algorithm participation tion
is advertised in IGP protocols.</t> is advertised in IGP protocols.</t>
<section anchor="IS-IS-ALG_TLV">
<section anchor="IS-IS-ALG_TLV" title="The IS-IS IP Algorithm Sub-TLV"> <name>The IS-IS IP Algorithm Sub-TLV</name>
<t>The IS-IS <xref target="ISO10589"/> IP Algorithm Sub-TLV is a sub-TLV <t>The IS-IS <xref target="ISO10589"/> IP Algorithm Sub-TLV is a
of the sub-TLV of the IS-IS Router Capability TLV <xref target="RFC7981"/>
IS-IS Router Capability TLV <xref target="RFC7981"/> and has the followi and has the following format:
ng format: </t>
<figure align="center" anchor="ISISAlg" <figure anchor="ISISAlg" align="center">
title="IS-IS IP Algorithm Sub-TLV"> <name>IS-IS IP Algorithm Sub-TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork align="center"><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n | | Algorithm 1 | Algorithm 2 | Algorithm ... | Algorithm n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <list style="symbols"> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type (1 octet): IP Algorithm Sub-TLV (Value 29)</t> </figure>
<dl spacing="normal" newline="false">
<t>Length (1 octet): Variable</t> <dt>Type (1 octet):</dt> <dd>IP Algorithm Sub-TLV (Value 29)</dd>
<dt>Length (1 octet):</dt> <dd>Variable</dd>
<t>Algorithm (1 octet): Value from 128 to 255.</t> <dt>Algorithm (1 octet):</dt> <dd>Value from 128 to 255</dd>
</list></t> </dl>
<t>The IP Algorithm Sub-TLV <bcp14>MUST</bcp14> be propagated
<t>The IP Algorithm Sub-TLV MUST be propagated throughout the level throughout the level and <bcp14>MUST NOT</bcp14> be advertised across
and MUST NOT be advertised across level boundaries. Therefore, the S level boundaries. Therefore, the S bit in the Router Capability TLV,
bit in the Router Capability TLV, in which the IP Algorithm Sub-TLV is in which the IP Algorithm Sub-TLV is advertised, <bcp14>MUST
advertised, MUST NOT be set.</t> NOT</bcp14> be set.</t>
<t>The IP Algorithm Sub-TLV is optional. It <bcp14>MUST NOT</bcp14> be
<t>The IP Algorithm Sub-TLV is optional. It MUST NOT be advertised advertised more than once at a given level. A router receiving
more than once at a given level. A router receiving multiple IP multiple IP Algorithm sub-TLVs from the same originator
Algorithm sub-TLVs from the same originator MUST select the first <bcp14>MUST</bcp14> select the first advertisement in the
advertisement in the lowest-numbered LSP and subsequent instances of lowest-numbered Link State PDU (LSP), and subsequent instances of the IP
the IP Algorithm Sub-TLV MUST be ignored.</t> Algorithm
Sub-TLV <bcp14>MUST</bcp14> be ignored.</t>
<t>Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored <t>Algorithms outside the Flex-Algorithm range (128-255)
by the receiver. This situation SHOULD be logged as an error.</t> <bcp14>MUST</bcp14> be ignored by the receiver. This situation
<bcp14>SHOULD</bcp14> be logged as an error.</t>
<t>The IP Flex-Algorithm participation advertised in the IS-IS IP Algori <t>The IP Flex-Algorithm participation advertised in the IS-IS IP
thm Algorithm Sub-TLV is topology independent. When a router advertises
Sub-TLV is topology independent. When a router advertises participation in the IS-IS IP Algorithm Sub-TLV, the participation
participation in the IS-IS IP Algorithm Sub-TLV, the participation appli applies to all topologies in which the advertising node
es participates.</t>
to all topologies in which the advertising node participates.</t>
</section> </section>
<section anchor="OSPF-ALG_TLV">
<section anchor="OSPF-ALG_TLV" title="The OSPF IP Algorithm TLV"> <name>The OSPF IP Algorithm TLV</name>
<t>The OSPF <xref target="RFC2328"/> IP Algorithm TLV is a top-level TLV <t>The OSPF <xref target="RFC2328"/> IP Algorithm TLV is a top-level
of the TLV of the Router Information Opaque Link State Advertisement (LSA)
<xref target="RFC7770"> Router Information Opaque LSA</xref> and has the <xref target="RFC7770"/> and has the following format: </t>
following format: <figure align="center" anchor="OSPFAlg" <figure anchor="OSPFAlg" align="center">
title="OSPF IP Algorithm TLV"> <name>OSPF IP Algorithm TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork align="center"><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm n | | | Algorithm 1 | Algorithm... | Algorithm n | |
+- -+ +- -+
| | | |
+ + + +
]]></artwork> ]]></artwork>
</figure> <list style="symbols"> </figure>
<t>Type (2 octets): IP Algorithm TLV (Value TBD1 by IANA)</t> <dl spacing="normal" newline="false">
<dt>Type (2 octets):</dt> <dd>IP Algorithm TLV (21)</dd>
<t>Length( 2 octets): Variable</t> <dt>Length( 2 octets):</dt> <dd>Variable</dd>
<dt>Algorithm (1 octet):</dt> <dd>Value from 128 to 255</dd>
<t>Algorithm (1 octet): Value from 128 to 255.</t> </dl>
</list></t> <t>The IP Algorithm TLV is optional. It <bcp14>MUST</bcp14> only be
advertised once in the Router Information LSA.</t>
<t>The IP Algorithm TLV is optional. It MUST only be advertised once <t>Algorithms outside the Flex-Algorithm range (128-255)
in the Router Information LSA.</t> <bcp14>MUST</bcp14> be ignored by the receiver. This situation
<bcp14>SHOULD</bcp14> be logged as an error.</t>
<t>Algorithms outside the Flex-Algorithm range (128-255) MUST be ignored
by the receiver. This situation SHOULD be logged as an error.</t>
<t>When multiple IP Algorithm TLVs are received from a given router, <t>When multiple IP Algorithm TLVs are received from a given router,
the receiver MUST use the first occurrence of the TLV in the Router the receiver <bcp14>MUST</bcp14> use the first occurrence of the TLV
Information LSA. If the IP Algorithm TLV appears in multiple Router Info in the Router Information LSA. If the IP Algorithm TLV appears in
rmation multiple Router Information LSAs that have different flooding scopes,
LSAs that have different flooding scopes, the IP Algorithm TLV in the Ro the IP Algorithm TLV in the Router Information LSA with the
uter area-scoped flooding scope <bcp14>MUST</bcp14> be used. If the IP
Information LSA with the area-scoped flooding scope MUST be used. If the Algorithm TLV appears in multiple Router Information LSAs that have
IP Algorithm TLV appears in multiple Router Information LSAs that have t the same flooding scope, the IP Algorithm TLV in the Router
he same Information LSA with the numerically smallest Instance ID (Opaque ID
flooding scope, the IP Algorithm TLV in the Router Information LSA with for OSPFv2 or Link State ID for OSPFv3) <bcp14>MUST</bcp14> be used,
the and subsequent instances of the IP Algorithm TLV <bcp14>MUST</bcp14>
numerically smallest Instance ID (Opaque ID for OSPFv2 or Link State ID be ignored.</t>
for OSPFv3)
MUST be used and subsequent instances of the IP Algorithm TLV MUST be ig
nored.</t>
<t>The Router Information LSA can be advertised at any of the defined fl
ooding
scopes (link, area, or Autonomous System (AS)). For the purpose of IP
Algorithm TLV advertisement, area or Autonomous System scoped flooding i
s REQUIRED.
The AS flooding scope SHOULD NOT be used unless local configuration poli
cy
on the originating router indicates domain-wide flooding.</t>
<t>The IP Flex-Algorithm participation advertised in the OSPF IP Algorit <t>The Router Information LSA can be advertised at any of the defined
hm flooding scopes (link, area, or Autonomous System (AS)). For the
purpose of IP Algorithm TLV advertisement, area- or AS-scoped flooding
is <bcp14>REQUIRED</bcp14>. The AS flooding scope <bcp14>SHOULD
NOT</bcp14> be used unless local configuration policy on the
originating router indicates domain-wide flooding.</t>
<t>The IP Flexible Algorithm participation advertised in the OSPF IP Alg
orithm
TLV is topology independent. When a router advertises participation in TLV is topology independent. When a router advertises participation in
OSPF IP Algorithm TLV, the participation applies to all topologies in OSPF IP Algorithm TLV, the participation applies to all topologies in
which the advertising node participates.</t> which the advertising node participates.</t>
</section> </section>
</section> </section>
<section anchor="ASSOCIATE">
<section anchor="ASSOCIATE" <name>Advertising IP Flexible Algorithm Reachability</name>
title="Advertising IP Flex-Algorithm Reachability">
<t>To be able to associate the prefix with the Flex-Algorithm, the <t>To be able to associate the prefix with the Flex-Algorithm, the
existing prefix reachability advertisements cannot be used, because existing prefix reachability advertisements cannot be used, because
they advertise the prefix reachability in default algorithm 0. Instead, they advertise the prefix reachability in default algorithm 0. Instead,
new IP Flex-Algorithm reachability advertisements are defined in IS-IS new IP Flexible Algorithm reachability advertisements are defined in IS-IS
and OSPF.</t> and OSPF.</t>
<t>The M-flag in the FAD is not applicable to IP Algorithm Prefixes. Any I P <t>The M-flag in the FAD is not applicable to IP Algorithm Prefixes. Any I P
Algorithm Prefix advertisement includes the Algorithm and Metric fields. Algorithm Prefix advertisement includes the Algorithm and Metric fields.
When an IP Algorithm Prefix is advertised between areas or domains, the When an IP Algorithm Prefix is advertised between areas or domains, the
metric field in the IP Algorithm Prefix advertisement MUST be used metric field in the IP Algorithm Prefix advertisement <bcp14>MUST</bcp14> be used
irrespective of the M-flag in the FAD advertisement.</t> irrespective of the M-flag in the FAD advertisement.</t>
<section anchor="IS-IS-IPV4_PFX_TLV">
<section anchor="IS-IS-IPV4_PFX_TLV" <name>The IS-IS IPv4 Algorithm Prefix Reachability TLV</name>
title="The IS-IS IPv4 Algorithm Prefix Reachability TLV"> <t>The IPv4 Algorithm Prefix Reachability top-level TLV is defined for a
<t>The IPv4 Algorithm Prefix Reachability top-level TLV is defined for a dvertising IPv4 Flexible Algorithm
dvertising IPv4 Flex-Algorithm
Prefix Reachability in IS-IS.</t> Prefix Reachability in IS-IS.</t>
<t>This new TLV shares the sub-TLV space defined for TLVs Advertising Pr efix <t>This new TLV shares the sub-TLV space defined for TLVs Advertising Pr efix
Reachability.</t> Reachability.</t>
<t>The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following <t>The IS-IS IPv4 Algorithm Prefix Reachability TLV has the following
format: <figure anchor="ISISipv4" title="IS-IS IPv4 Algorithm Prefix Rea format: </t>
chability TLV"> <figure anchor="ISISipv4" align="center">
<artwork><![CDATA[ 0 1 2 <name>IS-IS IPv4 Algorithm Prefix Reachability TLV</name>
3 <artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | Rsvd | MTID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Rsvd | MTID |
]]></artwork> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure> <list style="symbols"> ]]></artwork>
<t>Type (1 octet): IPv4 Algorithm Prefix Reachability TLV (Value 126 </figure>
).</t> <dl spacing="normal" newline="false">
<dt>Type (1 octet):</dt> <dd>IPv4 Algorithm Prefix Reachability TLV
<t>Length (1 octet): Variable based on number of prefix entries enco (Value 126)</dd>
ded</t> <dt>Length (1 octet):</dt> <dd>Variable based on number of prefix
entries encoded</dd>
<t>Rsvd (4 bits): Reserved for future use. They MUST be set to <dt>Rsvd (4 bits):</dt> <dd>Reserved for future use. They
zero on transmission and MUST be ignored on receipt.</t> <bcp14>MUST</bcp14> be set to zero on transmission and
<bcp14>MUST</bcp14> be ignored on receipt.</dd>
<t>MTID (12 bits): Multitopology Identifier as defined in <dt>MTID (12 bits):</dt> <dd>Multitopology Identifier as defined in
[RFC5120]. Note that the value 0 is legal.</t> <xref target="RFC5120" format="default"/>. Note that the value 0 is
</list></t> legal.</dd>
</dl>
<t>Followed by one or more prefix entries of the form: <t>Followed by one or more prefix entries of the form:</t>
<figure anchor="ISISpfxentry" title="IS-IS IPv4 Algorithm Prefix Reachab <figure anchor="ISISpfxentry" align="center">
ility TLV"> <name>IS-IS IPv4 Algorithm Prefix Reachability TLV</name>
<artwork><![CDATA[ 0 1 2 <artwork align="center"><![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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | | Flags | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pfx Length | Prefix (variable)... | Pfx Length | Prefix (variable)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-tlv-len | Sub-TLVs (variable) . . . | | Sub-tlv-len | Sub-TLVs (variable) . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> <list style="symbols"> </figure>
<t>Metric (4 octets): Metric information as defined in <xref target=
"RFC5305"/>.</t>
<t>Flags (1 octet): <figure>
<artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure> <list style="hanging">
<t>D-flag: When the Prefix is leaked from level-2 to level-1,
the D bit MUST be set. Otherwise, this bit MUST be clear.
Prefixes with the D bit set MUST NOT be leaked from level-1 to
level-2. This is to prevent looping.</t>
</list></t>
<t>Algorithm (1 octet): Associated Algorithm from 128 to 255.</t>
<t>Prefix Len (1 octet): Prefix length measured in bits.</t>
<t>Prefix (variable length): Prefix mapped to Flex-Algorithm.</t>
<t>Optional Sub-TLV-length (1 octet): Number of octets used by
sub-TLVs</t>
<t>Optional sub-TLVs (variable length).</t>
</list></t>
<t>If the Algorithms in the IS-IS IPv4 Algorithm Prefix Reachability TLV <dl spacing="normal" newline="false">
is outside <dt>Metric (4 octets):</dt> <dd>Metric information as defined in <xref
the Flex-Algorithm range (128-255), the IS-IS IPv4 Algorithm Prefix Reac target="RFC5305"/></dd>
hability <dt>Flags (1 octet):</dt>
TLV MUST be ignored by the receiver. This situation SHOULD be logged as <dd>
an error.</t> <artwork><![CDATA[
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|D| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
<dl newline="false" spacing="normal">
<dt>D-flag:</dt>
<dd>The D-flag is described as the "up/down bit" in <xref
target="RFC5305" sectionFormat="of" section="4.1"/>. When the
Prefix is leaked from level 2 to level 1, the D bit
<bcp14>MUST</bcp14> be set. Otherwise, this bit
<bcp14>MUST</bcp14> be clear. Prefixes with the D bit set
<bcp14>MUST NOT</bcp14> be leaked from level 1 to level 2. This
is to prevent looping.</dd>
<dt>The remaining bits:</dt>
<dd>Are reserved for future use. They <bcp14>MUST</bcp14> be set
to zero on transmission and <bcp14>MUST</bcp14> be ignored on
receipt.</dd>
</dl>
</dd>
<dt>Algorithm (1 octet):</dt> <dd>Associated Algorithm from 128 to
255</dd>
<dt>Prefix Len (1 octet):</dt> <dd>Prefix length measured in
bits</dd>
<dt>Prefix (variable length):</dt> <dd>Prefix mapped to
Flex-Algorithm</dd>
<dt>Optional Sub-TLV-length (1 octet):</dt> <dd>Number of octets
used by sub-TLVs</dd>
<dt>Optional sub-TLVs (variable length)</dt>
<dd></dd>
</dl>
<t>If the Algorithms in the IS-IS IPv4 Algorithm Prefix Reachability
TLV are outside the Flex-Algorithm range (128-255), the IS-IS IPv4
Algorithm Prefix Reachability TLV <bcp14>MUST</bcp14> be ignored by
the receiver. This situation <bcp14>SHOULD</bcp14> be logged as an
error.</t>
<t> If a router receives multiple IPv4 Algorithm Prefix Reachability <t> If a router receives multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix from the same originator, it advertisements for the same prefix from the same originator, it
MUST select the first advertisement in <bcp14>MUST</bcp14> select the first advertisement in
the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm the lowest-numbered LSP and ignore any subsequent IPv4 Algorithm
Prefix Reachability advertisements for the same prefix.</t> Prefix Reachability advertisements for the same prefix.</t>
<t>If a router receives multiple IPv4 Algorithm Prefix Reachability <t>If a router receives multiple IPv4 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, advertisements for the same prefix, from different originators,
where all of them do not advertise the same algorithm, it MUST ignore al where all of them do not advertise the same algorithm, it <bcp14>MUST</b
l of them and cp14> ignore all of them and
MUST NOT install any forwarding entries based on these <bcp14>MUST NOT</bcp14> install any forwarding entries based on these
advertisements. This situation SHOULD be logged as an error.</t> advertisements. This situation <bcp14>SHOULD</bcp14> be logged as an er
ror.</t>
<t>In cases where a prefix advertisement is received in both a IPv4 <t>In cases where a prefix advertisement is received in both an IPv4
Prefix Reachability TLV (<xref target="RFC5305"/>, <xref target="RFC5120 Prefix Reachability TLV <xref target="RFC5305"/> <xref
"/>) target="RFC5120"/> and an IPv4 Algorithm Prefix Reachability TLV, the
and an IPv4 Algorithm Prefix Reachability TLV, the IPv4 Prefix Reachabil IPv4 Prefix Reachability advertisement <bcp14>MUST</bcp14> be
ity preferred when installing entries in the forwarding plane.</t>
advertisement MUST be preferred when installing entries in the forwardin
g plane.</t>
</section> </section>
<section anchor="IS-IS-IPV6_PFX_TLV">
<section anchor="IS-IS-IPV6_PFX_TLV" <name>The IS-IS IPv6 Algorithm Prefix Reachability TLV</name>
title="The IS-IS IPv6 Algorithm Prefix Reachability TLV">
<t>The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the <t>The IS-IS IPv6 Algorithm Prefix Reachability TLV is identical to the
IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a IS-IS IPv4 Algorithm Prefix Reachability TLV, except that it has a
distinct type. The type is 127.</t> distinct type. The type is 127.</t>
<t>If the Algorithms in the IS-IS IPv6 Algorithm Prefix Reachability
<t>If the Algorithms in the IS-IS IPv6 Algorithm Prefix Reachability TLV TLV are outside the Flex-Algorithm range (128-255), the IS-IS IPv6
is outside Algorithm Prefix Reachability TLV <bcp14>MUST</bcp14> be ignored by
the Flex-Algorithm range (128-255), the IS-IS IPv6 Algorithm Prefix Reac the receiver. This situation <bcp14>SHOULD</bcp14> be logged as an
hability error.</t>
TLV MUST be ignored by the receiver. This situation SHOULD be logged as
an error.</t>
<t> If a router receives multiple IPv6 Algorithm Prefix Reachability <t> If a router receives multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix from the same originator, it advertisements for the same prefix from the same originator, it
MUST select the first advertisement in <bcp14>MUST</bcp14> select the first advertisement in
the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm the lowest-numbered LSP and ignore any subsequent IPv6 Algorithm
Prefix Reachability advertisements for the same prefix.</t> Prefix Reachability advertisements for the same prefix.</t>
<t>If a router receives multiple IPv6 Algorithm Prefix Reachability <t>If a router receives multiple IPv6 Algorithm Prefix Reachability
advertisements for the same prefix, from different originators, advertisements for the same prefix, from different originators,
where all of them do not advertise the same algorithm, it MUST ignore al where all of them do not advertise the same algorithm, it <bcp14>MUST</b
l of them and cp14> ignore all of them and
MUST NOT install any forwarding entries based on these <bcp14>MUST NOT</bcp14> install any forwarding entries based on these
advertisements. This situation SHOULD be logged as an error.</t> advertisements. This situation <bcp14>SHOULD</bcp14> be logged as an err
or.</t>
<t>In cases where a prefix advertisement is received in both an IPv6 <t>In cases where a prefix advertisement is received in both an IPv6
Prefix Reachability TLV (<xref target="RFC5308"/>, <xref target="RFC5120 Prefix Reachability TLV <xref target="RFC5308"/> <xref
"/>) target="RFC5120"/> and an IPv6 Algorithm Prefix Reachability TLV, the
and an IPv6 Algorithm Prefix Reachability TLV, the IPv6 Prefix Reachabil IPv6 Prefix Reachability advertisement <bcp14>MUST</bcp14> be
ity preferred when installing entries in the forwarding plane.</t>
advertisement MUST be preferred when installing entries in the forwardin
g plane.</t>
<t>In cases where a prefix advertisement is received in both an IS-IS SR v6 <t>In cases where a prefix advertisement is received in both an IS-IS SR v6
Locator TLV <xref target="RFC9352"/> and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver Locator TLV <xref target="RFC9352"/> and in IS-IS IPv6 Algorithm Prefix Reachability TLV, the receiver
MUST ignore both of them and MUST NOT install any forwarding entries bas <bcp14>MUST</bcp14> ignore both of them and <bcp14>MUST NOT</bcp14> inst
ed all any forwarding entries based
on these advertisements. This situation SHOULD be logged as an error.</t on these advertisements. This situation <bcp14>SHOULD</bcp14> be logged
> as an error.</t>
</section> </section>
<section anchor="OSPF-IPV4_PFX_TLV">
<section anchor="OSPF-IPV4_PFX_TLV" <name>The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV</name>
title="The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV"> <t>A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
<t>A new Sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP advertising IP Algorithm Prefix Reachability in OSPFv2, the OSPFv2 IP
Algorithm Prefix Reachability Sub-TLV.</t> Algorithm Prefix Reachability Sub-TLV.</t>
<t>The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the <t>The OSPFv2 IP Algorithm Prefix Reachability Sub-TLV has the
following format:</t> following format:</t>
<figure anchor="OSPFvpfx2" align="center">
<t><figure anchor="OSPFvpfx2" title="OSPFv2 IP Algorithm Prefix Reachabi <name>OSPFv2 IP Algorithm Prefix Reachability Sub-TLV</name>
lity Sub-TLV"> <artwork align="center"><![CDATA[
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | Algorithm | Flags | Reserved | | MT-ID | Algorithm | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="false">
<t>Type (2 octets) : The value is TBD2.</t> <dt>Type (2 octets):</dt> <dd>The value is 6</dd>
<dt>Length (2 octets):</dt> <dd>8</dd>
<t>Length (2 octets): 8</t> <dt>MT-ID (1 octet):</dt> <dd>Multi-Topology ID as defined in <xref
target="RFC4915"/></dd>
<t>MT-ID (1 octet): Multi-Topology ID as defined in <xref <dt>Algorithm (1 octet):</dt> <dd>Associated Algorithm from 128 to
target="RFC4915"/></t> 255</dd>
<dt>Flags (1 octet):</dt>
<t>Algorithm (1 octet): Associated Algorithm from 128 to 255.</t> <dd><t>The following flags are defined:</t>
<artwork><![CDATA[
<t>Flags: (1 octet): The following flags are defined: 0 1 2 3 4 5 6 7 8
<figure> +-+-+-+-+-+-+-+-+-+
align="center"> |E| Reserved |
<artwork> +-+-+-+-+-+-+-+-+-+
]]></artwork>
0 1 2 3 4 5 6 7 8 <t>Where:</t>
+-+-+-+-+-+-+-+-+-+ <dl spacing="normal" newline="false">
|E| Reserved | <dt>E bit:</dt> <dd>The same as the E bit defined in
+-+-+-+-+-+-+-+-+-+ <xref target="RFC2328" sectionFormat="of" section="A.4.5"/>.</dd>
<dt>The remaining bits:</dt> <dd>Are reserved for future
where:</artwork> use. They <bcp14>MUST</bcp14> be set to zero on transmission and
</figure></t> <bcp14>MUST</bcp14> be ignored on receipt.</dd>
</dl>
<t><list> </dd>
<dt>Reserved (1 octet):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
<t>bit E: Same as bit E defined in section A.4.5 of <xref target= on transmission and <bcp14>MUST</bcp14> be ignored on
"RFC2328"/>.</t> reception.</dd>
<dt>Metric (4 octets):</dt> <dd>The algorithm-specific metric
<t>The remaining bits, are reserved for future use. They MUST be value. The metric value of 0XFFFFFFFF <bcp14>MUST</bcp14> be
set to zero on transmission and MUST be ignored on receipt.</t> considered unreachable.</dd>
</dl>
</list></t> <t>If the Algorithms in the OSPFv2 IP Algorithm Prefix Reachability
Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPFv2 IP
<t>Reserved: (1 octet). SHOULD be set to 0 on transmission and Algorithm Prefix Reachability Sub-TLV <bcp14>MUST</bcp14> be ignored
MUST be ignored on reception.</t> by the receiver. This situation <bcp14>SHOULD</bcp14> be logged as an
error.</t>
<t>Metric (4 octets): The algorithm-specific metric value. The metri
c
value of 0XFFFFFFFF MUST be considered as unreachable.</t>
</list></t>
<t>If the Algorithms in the OSPFv2 IP Algorithm Prefix Reachability Sub-
TLV is outside
the Flex-Algorithm range (128-255), the OSPFv2 IP Algorithm Prefix Reach
ability
Sub-TLV MUST be ignored by the receiver. This situation SHOULD be logged
as an error.</t>
<t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix <t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV, MUST Reachability Sub-TLVs in the same OSPFv2 Extended Prefix TLV
select the first advertisement of this Sub-TLV and MUST ignore all <bcp14>MUST</bcp14> select the first advertisement of this sub-TLV and
remaining occurences of this Sub-TLV in the OSPFv2 Extended Prefix <bcp14>MUST</bcp14> ignore all remaining occurrences of this sub-TLV in
TLV.</t> the OSPFv2 Extended Prefix TLV.</t>
<t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix <t>An OSPFv2 router receiving multiple OSPFv2 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators, Reachability TLVs for the same prefix from different originators
where all of them do not advertise the same algorithm, MUST ignore all o where all of them do not advertise the same algorithm <bcp14>MUST</bcp14
f them and MUST NOT > ignore all of them and <bcp14>MUST NOT</bcp14>
install any forwarding entries based on these advertisements. install any forwarding entries based on these advertisements.
This situation SHOULD be logged as an error.</t> This situation <bcp14>SHOULD</bcp14> be logged as an error.</t>
<t>In cases where a prefix advertisement is received in any of the <t>In cases where a prefix advertisement is received in any of the
LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv 2 LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv 2
IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachability
advertisement for algorithm 0 MUST be used and all occurences of the advertisement for algorithm 0 <bcp14>MUST</bcp14> be used, and all occur
OSPFv2 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.</t> rences of the
OSPFv2 IP Algorithm Prefix Reachability Sub-TLV <bcp14>MUST</bcp14> be i
<t>When computing the IP Algorithm Prefix reachability in OSPFv2, only i gnored.</t>
nformation <t>When computing the IP Algorithm Prefix reachability in OSPFv2, only
present in the OSPFv2 Extended Prefix TLV MUST be used. There will not b information present in the OSPFv2 Extended Prefix TLV
e any <bcp14>MUST</bcp14> be used. There will not be any information
information advertised for the IP Algorithm Prefix in any of the OSPFv2 advertised for the IP Algorithm Prefix in any of the OSPFv2 LSAs that
LSAs that advertise prefix reachability for algorithm 0. For the IP Algo advertise prefix reachability for algorithm 0. For the IP Algorithm
rithm Prefix Prefix, the OSPFv2 Extended Prefix TLV is used to advertise the prefix
the OSPFv2 Extended Prefix TLV is used to advertise the prefix reachabil reachability, unlike for algorithm 0 prefixes, where the OSPFv2
ity, unlike Extended Prefix TLV is only used to advertise additional attributes --
for algorithm 0 prefixes, where the OSPFv2 Extended Prefix TLV is only u but not the reachability itself.</t>
sed to advertise <section anchor="OSPFV2_FA-SUBTLV">
additional attributes, but not the reachability itself.</t> <name>The OSPFv2 IP Forwarding Address Sub-TLV</name>
<t>A new sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
<section anchor="OSPFV2_FA-SUBTLV"
title="The OSPFv2 IP Forwarding Address Sub-TLV">
<t>A new Sub-TLV of the OSPFv2 Extended Prefix TLV is defined for
advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address Sub- TLV.</t> advertising IP Forwarding Address, the OSPFv2 IP Forwarding Address Sub- TLV.</t>
<t>The OSPFv2 IP Forwarding Address Sub-TLV has the
<t>The OSPFv2 IP Forwarding Address Sub-TLV has the
following format:</t> following format:</t>
<figure anchor="OSPFV2_FA" align="center">
<t><figure anchor="OSPFV2_FA" title="OSPFv2 IP Forwarding Address Sub-TL <name>OSPFv2 IP Forwarding Address Sub-TLV</name>
V"> <artwork align="center"><![CDATA[
<artwork><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forwarding Address | | Forwarding Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure></t> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</figure>
<t><list style="symbols"> <dl spacing="normal" newline="false">
<t>Type (2 octets) : The value is TBD4.</t> <dt>Type (2 octets):</dt> <dd>The value is 7</dd>
<dt>Length (2 octets):</dt> <dd>4</dd>
<t>Length (2 octets): 4</t> <dt>Forwarding Address (4 octets):</dt> <dd>The same as defined in <
xref target="RFC2328" sectionFormat="of" section="A.4.5"/></dd>
<t>Forwarding Address (4 octets): Same as defined in section A.4.5 o </dl>
f <t>The OSPFv2 IP Forwarding Address Sub-TLV <bcp14>MUST NOT</bcp14>
<xref target="RFC2328"/>.</t> be used for computing algorithm 0 prefix reachability and
<bcp14>MUST</bcp14> be ignored for algorithm 0 prefixes.</t>
</list></t> <t>The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is
not present, the forwarding address for computing the IP Algorithm
<t>The OSPFv2 IP Forwarding Address Sub-TLV MUST NOT be used Prefix reachability is assumed to be equal to 0.0.0.0.</t>
for computing algorithm 0 prefix reachability and MUST be ignored fo
r
algorithm 0 prefixes.</t>
<t>The OSPFv2 IP Forwarding Address Sub-TLV is optional. If it is no
t present,
the forwarding address for computing the IP Algorithm Prefix reachab
ility
is assumed to be equal to 0.0.0.0.</t>
<t>The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to Au <t>The OSPFv2 IP Forwarding Address Sub-TLV is only applicable to AS E
tonomous System xternal and Not-So-Stubby Area (NSSA) External route types. If the
(AS) External and Not-So-Stubby Area (NSSA) External route types. I
f the
OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 Ex tended OSPFv2 IP Forwarding Address Sub-TLV is advertised in the OSPFv2 Ex tended
Prefix TLV that has the Route Type field set to any other type, the OSPFv2 Prefix TLV that has the Route Type field set to any other type, the OSPFv2
IP Forwarding Address Sub-TLV MUST be ignored.</t> IP Forwarding Address Sub-TLV <bcp14>MUST</bcp14> be ignored.</t>
</section> </section>
</section> </section>
<section anchor="OSPFV3_ALGTLV">
<section anchor="OSPFV3_ALGTLV" <name>The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV</name>
title="The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV">
<t>The OSPFv3 <xref target="RFC5340"/> IP Algorithm Prefix Reachability Sub-TLV <t>The OSPFv3 <xref target="RFC5340"/> IP Algorithm Prefix Reachability Sub-TLV
is defined for advertisement of the IP Algorithm Prefix Reachability in OSPFv3.</t> is defined for advertisement of the IP Algorithm Prefix Reachability in OSPFv3.</t>
<t>The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of <t>The OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is a sub-TLV of
the following OSPFv3 TLVs defined in <xref target="RFC8362"/>: <list the following OSPFv3 TLVs defined in <xref target="RFC8362"/>: </t>
style="symbols"> <ul spacing="normal">
<t>Intra-Area-Prefix TLV</t> <li>Intra-Area-Prefix TLV</li>
<li>Inter-Area-Prefix TLV</li>
<t>Inter-Area-Prefix TLV</t> <li>External-Prefix TLV</li>
</ul>
<t>External-Prefix TLV</t>
</list></t>
<t>The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is <t>The format of OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
shown below:</t> shown below:</t>
<figure anchor="OSPFv3pfx" align="center">
<t><figure anchor="OSPFv3pfx" title="OSPFv3 IP Algorithm Prefix Reachabi <name>OSPFv3 IP Algorithm Prefix Reachability Sub-TLV</name>
lity Sub-TLV"> <artwork align="center"><![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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | Reserved |
| Algorithm | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metric |
| Metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>Where:<list> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<t>Type (2 octets): The value is TBD3.</t> </figure>
<t>Where:</t>
<t>Length (2 octets): 8.</t> <dl spacing="normal" newline="false">
<dt>Type (2 octets):</dt> <dd>The value is 35</dd>
<t>Algorithm (1 octet): Associated Algorithm from 128 to 255.</t> <dt>Length (2 octets):</dt> <dd>8</dd>
<dt>Algorithm (1 octet):</dt> <dd>Associated Algorithm from 128 to
<t>Reserved: (3 octets). SHOULD be set to 0 on transmission and 255</dd>
MUST be ignored on reception.</t> <dt>Reserved (3 octets):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
on transmission and <bcp14>MUST</bcp14> be ignored on
<t>Metric (4 octets): The algorithm-specific metric value. The metri reception.</dd>
c <dt>Metric (4 octets):</dt> <dd>The algorithm-specific metric
value of 0XFFFFFFFF MUST be considered as unreachable.</t> value. The metric value of 0XFFFFFFFF <bcp14>MUST</bcp14> be
</list></t> considered unreachable.</dd>
</dl>
<t>If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability Sub- <t>If the Algorithms in the OSPFv3 IP Algorithm Prefix Reachability
TLV is outside Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPFv3 IP
the Flex-Algorithm range (128-255), the OSPFv3 IP Algorithm Prefix Reach Algorithm Prefix Reachability Sub-TLV <bcp14>MUST</bcp14> be ignored
ability by the receiver. This situation <bcp14>SHOULD</bcp14> be logged as an
Sub-TLV MUST be ignored by the receiver. This situation SHOULD be logged error.</t>
as an error.</t>
<t>When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is <t>When the OSPFv3 IP Algorithm Prefix Reachability Sub-TLV is
present, the NU-bit in the PrefixOptions field of the parent TLV MUST be present, the NU-bit in the PrefixOptions field of the parent TLV
set. <bcp14>MUST</bcp14> be set. This is needed to prevent the OSPFv3 IP
This is needed to prevent the OSPFv3 IP Algorithm Prefix Reachability ad Algorithm Prefix Reachability advertisement from contributing to the
vertisement base algorithm reachability. If the NU-bit in the PrefixOptions field
from contributing to the base algorithm reachability. If the NU-bit in t of the parent TLV is not set, the OSPFv3 IP Algorithm Prefix Sub-TLV
he <bcp14>MUST</bcp14> be ignored by the receiver.</t>
PrefixOptions field of the parent TLV is not set, the OSPFv3 IP Algorit <t>The metric value in the parent TLV is <bcp14>RECOMMENDED</bcp14> to
hm be set to LSInfinity <xref target="RFC2328"/>. This recommendation is
Prefix Sub-TLV MUST be ignored by the receiver.</t> provided as a network troubleshooting convenience; if it is not
followed, the protocol will still function correctly.</t>
<t>The metric value in the parent TLV is RECOMMENDED to be set to LSInfi
nity
<xref target="RFC2328"/>. This recommendation is provided as a network t
roubleshooting
convenience; if it is not followed the protocol will still function corr
ectly.</t>
<t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix <t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability Sub-TLVs in the same parent TLV, MUST select the first Reachability Sub-TLVs in the same parent TLV <bcp14>MUST</bcp14> select
advertisement of this Sub-TLV and MUST ignore all remaining occurences the first
of this Sub-TLV in the parent TLV.</t> advertisement of this sub-TLV and <bcp14>MUST</bcp14> ignore all remaini
ng occurrences
of this sub-TLV in the parent TLV.</t>
<t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix <t>An OSPFv3 router receiving multiple OSPFv3 IP Algorithm Prefix
Reachability TLVs for the same prefix, from different originators, Reachability TLVs for the same prefix from different originators
where all of them do not advertise the same algorithm, MUST ignore all o where all of them do not advertise the same algorithm <bcp14>MUST</bcp14
f them and MUST NOT > ignore all of them and <bcp14>MUST NOT</bcp14>
install any forwarding entries based on these advertisements. install any forwarding entries based on these advertisements.
This situation SHOULD be logged as an error.</t> This situation <bcp14>SHOULD</bcp14> be logged as an error.</t>
<t>In cases where a prefix advertisement is received in any of the <t>In cases where a prefix advertisement is received in any of the
LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv 3 LSAs advertising the prefix reachability for algorithm 0 and in an OSPFv 3
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachab ility OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, only the prefix reachab ility
advertisement for algorithm 0 MUST be used and all occurences of the advertisement for algorithm 0 <bcp14>MUST</bcp14> be used, and all occur
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV MUST be ignored.</t> rences of the
OSPFv3 IP Algorithm Prefix Reachability Sub-TLV <bcp14>MUST</bcp14> be i
gnored.</t>
<t>In cases where a prefix advertisement is received in both an OSPFv3 S Rv6 Locator TLV <t>In cases where a prefix advertisement is received in both an OSPFv3 S Rv6 Locator TLV
and in an OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, the receiver and in an OSPFv3 IP Algorithm Prefix Reachability Sub-TLV, the receiver
MUST ignore both of them and MUST NOT install any forwarding entries bas <bcp14>MUST</bcp14> ignore both of them and <bcp14>MUST NOT</bcp14> inst
ed all any forwarding entries based
on these advertisements. This situation SHOULD be logged as an error.</t on these advertisements. This situation <bcp14>SHOULD</bcp14> be logged
> as an error.</t>
</section> </section>
<section anchor="IPFAAL">
<section anchor="IPFAAL" <name>The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV</name>
title="The OSPF IP Flexible Algorithm ASBR Metric Sub-TLV"> <t><xref target="RFC9350"/> defines the OSPF Flexible Algorithm ASBR
<t><xref target="RFC9350"/> defines Metric (FAAM) Sub-TLV that is used by an OSPFv2 or an OSPFv3 Area
the OSPF Flexible Algorithm ASBR Metric Sub-TLV (FAAM) that is used by Border Router (ABR) to advertise a Flex-Algorithm-specific metric
an OSPFv2 or an OSPFv3 ABR to advertise a Flex-Algorithm specific metric
associated with the corresponding ASBR LSA.</t> associated with the corresponding ASBR LSA.</t>
<t>As described in <xref target="RFC9350"/>, each data plane signals
<t>As described in <xref target="RFC9350"/> each data-plane signals its participation independently. IP Flexible Algorithm participation is
its participation independently. IP Flex-Algorithm participation is signaled independent of SR Flexible Algorithm participation. As a result
signaled independent of Segment Routing (SR) Flex-Algorithm ,
participation. As a result, the calculated topologies for SR and IP the calculated topologies for SR and IP Flexible Algorithm could be
Flex-Algorithm could be different. Such difference prevents the usage different. Such a difference prevents the usage of FAAM for the purpose
of FAAM for the purpose of the IP Flex-Algorithm.</t> of the IP Flexible Algorithm.</t>
<t>The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is <t>The OSPF IP Flexible Algorithm ASBR Metric (IPFAAM) Sub-TLV is
defined for the advertisement of the IP Flex-Algorithm specific metric defined for the advertisement of the IP Flex-Algorithm-specific metric
associated with an ASBR by the ABR.</t> associated with an ASBR by the ABR.</t>
<t>The IPFAAM Sub-TLV is a sub-TLV of the:</t>
<t>The IPFAAM Sub-TLV is a Sub-TLV of the: <list style="hanging"> <ul spacing="normal">
<t>- OSPFv2 Extended Inter-Area ASBR TLV as defined in <xref <li>OSPFv2 Extended Inter-Area ASBR TLV, as defined in <xref
target="RFC9350"/></t> target="RFC9350"/></li>
<li>OSPFv3 Inter-Area-Router TLV, as defined in <xref
<t>- OSPFv3 Inter-Area-Router TLV defined in <xref target="RFC8362"/></li>
target="RFC8362"/></t> </ul>
</list></t>
<t>The OSPF IPFAAM Sub-TLV has the following format:</t> <t>The OSPF IPFAAM Sub-TLV has the following format:</t>
<t><figure anchor="OSPFfaal" title="OSPF IP Flexible Algorithm ASBR Met <figure anchor="OSPFfaal" align="center">
ric Sub-TLV"> <name>OSPF IP Flexible Algorithm ASBR Metric Sub-TLV</name>
<artwork><![CDATA[ <artwork align="center"><![CDATA[
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Reserved | | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
where: </figure>
]]></artwork> <t>Where:</t>
</figure> <list style="hanging"> <dl newline="false" spacing="normal">
<t>Type (2 octets): 2 (allocated by IANA) for OSPFv2, TBD5 for OSPFv <dt>Type (2 octets):</dt> <dd>2 (allocated by IANA) for OSPFv2, 36
3.</t> for OSPFv3</dd>
<dt>Length (2 octets):</dt> <dd>8</dd>
<t>Length (2 octets): 8.</t> <dt>Algorithm (1 octet):</dt> <dd>Associated Algorithm from 128 to
255</dd>
<t>Algorithm (1 octet): Associated Algorithm from 128 to 255.</t> <dt>Reserved (3 octets):</dt> <dd><bcp14>SHOULD</bcp14> be set to 0
on transmission and <bcp14>MUST</bcp14> be ignored on
<t>Reserved: (3 octets). SHOULD be set to 0 on transmission and reception</dd>
MUST be ignored on reception.</t> <dt>Metric (4 octets):</dt> <dd>The algorithm-specific metric
value</dd>
<t>Metric (4 octets): The algorithm-specific metric value.</t> </dl>
</list></t> <t>If the Algorithms in the OSPF IP Flexible Algorithm ASBR Metric
Sub-TLV are outside the Flex-Algorithm range (128-255), the OSPF IP
<t>If the Algorithms in the OSPF IP Flexible Algorithm ASBR Metric Sub-T Flexible Algorithm ASBR Metric Sub-TLV <bcp14>MUST</bcp14> be ignored
LV is outside by the receiver. This situation <bcp14>SHOULD</bcp14> be logged as an
the Flex-Algorithm range (128-255), the OSPF IP Flexible Algorithm ASBR error.</t>
Metric Sub-TLV
MUST be ignored by the receiver. This situation SHOULD be logged as an
error.</t>
<t>The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM <t>The usage of the IPFAAM Sub-TLV is similar to the usage of the FAAM
Sub-TLV defined in <xref target="RFC9350"/>, but it is Sub-TLV defined in <xref target="RFC9350"/>, but it is used to
used to advertise IP Flex-Algorithm metric.</t> advertise IP Flexible Algorithm metric.</t>
<t>An OSPF ABR <bcp14>MUST</bcp14> include the OSPF IPFAAM Sub-TLVs as
<t>An OSPF ABR MUST include the OSPF IPFAAM Sub-TLVs as part of the part of any IP Flexible Algorithm ASBR reachability advertisement
ASBR reachability advertisement between areas for every IP between areas.</t>
Flex-Algorithm in which it participates and the ASBR is reachable <t>The FAAM Sub-TLV as defined in <xref target="RFC9350"/> <bcp14>MUST
in.</t> NOT</bcp14> be used during IP Flexible Algorithm path calculation; the
IPFAAM Sub-TLV <bcp14>MUST</bcp14> be used instead.</t>
<t>The FAAM Sub-TLV as defined in <xref target="RFC9350"/>
MUST NOT be used during IP Flex-Algorithm path calculation, the IPFAAM
Sub-TLV MUST be used instead.</t>
</section> </section>
</section> </section>
<section>
<section title="Calculating of IP Flex-Algorithm Paths"> <name>Calculating of IP Flexible Algorithm Paths</name>
<t>The IP Flex-Algorithm is considered as yet another data-plane of the <t>The IP Flexible Algorithm is considered as yet another data plane of th
Flex-Algorithm as described in <xref target="RFC9350"/>.</t> e
Flexible Algorithm as described in <xref target="RFC9350"/>.</t>
<t>Participation in the IP Flex-Algorithm is signalled as described in <t>Participation in the IP Flexible Algorithm is signaled as described in
<xref target="PARTICIPATION"/> and is specific to the IP Flex-Algorithm <xref target="PARTICIPATION"/> and is specific to the IP Flexible Algorith
data-plane.</t> m
data plane.</t>
<t>Calculation of IP Flex-Algorithm paths follows what is described in <t>Calculation of IP Flexible Algorithm paths follows what is described in
<xref target="RFC9350"/>. This computation uses the IP <xref target="RFC9350"/>. This computation uses the IP
Flex-Algorithm data-plane participation and is independent of the Flex-Alg Flexible Algorithm data plane participation and is independent of the Flex
orithm ible Algorithm
calculation done for any other Flex-Algorithm data-plane (e.g., SR, calculation done for any other Flexible Algorithm data plane (e.g., SR,
SRv6).</t> SRv6).</t>
<t>The IP Flexible Algorithm data plane only considers participating nodes
<t>The IP Flex-Algorithm data-plane only considers participating nodes during the Flexible Algorithm calculation. When computing paths for a give
during the Flex-Algorithm calculation. When computing paths for a given n
Flex-Algorithm, all nodes that do not advertise participation for the IP Flex-Algorithm, all nodes that do not advertise participation for such IP
Flex-Algorithm, as described in <xref target="PARTICIPATION"/>, MUST be Flex-Algorithm, as described in <xref target="PARTICIPATION"/>, <bcp14>MUS
T</bcp14> be
pruned from the topology.</t> pruned from the topology.</t>
</section> </section>
<section>
<section title="IP Flex-Algorithm Forwarding"> <name>IP Flexible Algorithm Forwarding</name>
<t>The IP Algorithm Prefix Reachability advertisement as described in <xre <t>The IP Algorithm Prefix Reachability advertisement as described in <xre
f f target="PARTICIPATION"/> includes the MTID value that associates the
target="PARTICIPATION"/> includes the MTID value that associates the
prefix with a specific topology. Algorithm Prefix Reachability prefix with a specific topology. Algorithm Prefix Reachability
advertisement also includes an Algorithm value that explicitly advertisement also includes an Algorithm value that explicitly
associates the prefix with a specific Flex-Algorithm. The paths to the associates the prefix with a specific Flex-Algorithm. The paths to the
prefix MUST be calculated using the specified Flex-Algorithm in the prefix <bcp14>MUST</bcp14> be calculated using the specified Flex-Algorith m in the
associated topology.</t> associated topology.</t>
<t>Forwarding entries for the IP Flex-Algorithm prefixes advertised in <t>Forwarding entries for the IP Flex-Algorithm prefixes advertised in
IGPs MUST be installed in the forwarding plane of the receiving IP IGPs <bcp14>MUST</bcp14> be installed in the forwarding plane of the recei ving IP
Flex-Algorithm prefix capable routers when they participate in the Flex-Algorithm prefix capable routers when they participate in the
associated topology and algorithm. Forwarding entries for IP associated topology and algorithm. Forwarding entries for IP
Flex-Algorithm prefixes associated with Flex-Algorithms in which the Flex-Algorithm prefixes associated with Flex-Algorithms in which the
node is not participating MUST NOT be installed in the forwarding node is not participating <bcp14>MUST NOT</bcp14> be installed in the forw arding
plane.</t> plane.</t>
</section> </section>
<section>
<section title="Deployment Considerations"> <name>Deployment Considerations</name>
<t>IGP Flex-Algorithm can be used by many data-planes. The original <t>IGP Flexible Algorithm can be used by many data planes. The original
specification was done for SR and SRv6, this specification adds IP as specification was done for SR and SRv6; this specification adds IP as
another data-plane that can use IGP Flex-Algorithm. Other data-planes another data plane that can use IGP Flexible Algorithm. Other data planes
may be defined in the future. This section provides some details about may be defined in the future. This section provides some details about
the coexistence of the various data-planes of an IGP Flex-Algorithm.</t> the coexistence of the various data planes of an IGP Flexible Algorithm.</
t>
<t>Flex-Algorithm definition (FAD), as described in <xref <t>Flexible Algorithm Definition (FAD), as described in <xref target="RFC9
target="RFC9350"/>, is data-plane independent and is 350"/>, is data plane independent and is
used by all Flex-Algorithm data-planes.</t> used by all Flexible Algorithm data planes.</t>
<t>Participation in the Flexible Algorithm, as described in <xref target="
<t>Participation in the Flex-Algorithm, as described in <xref RFC9350"/>, is data plane specific.</t>
target="RFC9350"/>, is data-plane specific.</t> <t>Calculation of the Flexible Algorithm paths is data plane specific and
uses
<t>Calculation of the flex-algo paths is data-plane specific and uses data-plane-specific participation advertisements.</t>
data-plane specific participation advertisements.</t> <t>Data-plane-specific participation and calculation guarantee that the
forwarding of the traffic over the Flex-Algorithm data-plane-specific
<t>Data-plane specific participation and calculation guarantee that the
forwarding of the traffic over the Flex-Algorithm data-plane specific
paths is consistent between all nodes that apply the IGP Flex-Algorithm paths is consistent between all nodes that apply the IGP Flex-Algorithm
to the data-plane.</t> to the data plane.</t>
<t>Multiple data planes can use the same Flex-Algorithm value at the
<t>Multiple data-planes can use the same Flex-Algorithm value at the same time and, and as such, share the FAD for it. For example, SR-MPLS
same time and, and as such, share the FAD for it. For example, SR-MPLS and and IP can both use a common Flex-Algorithm. Traffic for SR-MPLS will be
IP can both use a common Flex-Algorithm. Traffic for SR-MPLS will be forwarded based on Flex-Algorithm-specific SR SIDs. Traffic for IP
forwarded based on Flex-algorithm specific SR SIDs. Traffic for IP Flex-Algorithm will be forwarded based on Flex-Algorithm-specific prefix
Flex-Algorithm will be forwarded based on Flex-Algorithm specific prefix reachability advertisements. Note that for a particular Flex-Algorithm,
reachability advertisements. Note that for a particular Flex-Algorithm, fo for a particular IP prefix, there will only be path(s) calculated and
r installed for a single data plane.</t>
a particular IP prefix, there will only be path(s) calculated and installe
d
for a single data-plane.</t>
</section> </section>
<section>
<section title="Protection"> <name>Protection</name>
<t>In many networks where IGP Flexible Algorithms are deployed, IGP <t>In many networks where IGP Flexible Algorithms are deployed, IGP
restoration will be fast and additional protection mechanisms will not restoration will be fast and additional protection mechanisms will not
be required. IGP restoration may be enhanced by Equal Cost Multipath be required. IGP restoration may be enhanced by Equal Cost Multipath
(ECMP).</t> (ECMP).</t>
<t>In other networks, operators can deploy additional protection <t>In other networks, operators can deploy additional protection
mechanisms. The following are examples:</t> mechanisms. The following are examples:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Loop-Free Alternates (LFAs) <xref target="RFC5286"/></li>
<t><xref target="RFC5286">Loop Free Alternates (LFA)</xref></t> <li>Remote Loop-Free Alternates (R-LFAs) <xref target="RFC7490"/></li>
</ul>
<t><xref target="RFC7490">Remote Loop Free Alternates (R-LFA) <t>LFA and R-LFA computations <bcp14>MUST</bcp14> be restricted to the
</xref></t> Flex-Algorithm topology and the computed backup next hops should be progra
</list>LFA and R-LFA computations MUST be restricted to the flex-algo mmed
topology and the computed backup nexthops should be programmed for the for the IP Flex-Algorithm prefixes.</t>
IP flex-algo prefixes.</t>
</section> </section>
<section anchor="IANA">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This specification updates the OSPF Router Information (RI) TLVs <t>This specification updates the "OSPF Router Information (RI) TLVs"
Registry as follows:</t>
<t/>
<texttable anchor="T1">
<ttcol>Value</ttcol>
<ttcol>TLV Name</ttcol>
<ttcol>Reference</ttcol>
<c>TBD1</c>
<c>IP Algorithm</c>
<c>This Document <xref target="OSPF-ALG_TLV"/></c>
</texttable>
<t>This document also updates the IS-IS "IS-IS Sub-TLVs for IS-IS Router C
APABILITY TLV" registry as
follows:</t>
<t/>
<texttable anchor="T2">
<ttcol>Value</ttcol>
<ttcol>TLV Name</ttcol>
<ttcol>Reference</ttcol>
<c>29</c>
<c>IP Algorithm</c>
<c>This Document <xref target="IS-IS-ALG_TLV"/></c>
</texttable>
<t>This document also updates the "IS-IS TLV Codepoints Registry"
registry as follows:</t> registry as follows:</t>
<t/> <table anchor="T1">
<thead>
<texttable anchor="T3"> <tr>
<ttcol>Value</ttcol> <th>Value</th>
<th>TLV Name</th>
<ttcol>TLV Name</ttcol> <th>Reference</th>
</tr>
<ttcol>IIH</ttcol> </thead>
<tbody>
<ttcol>LSP</ttcol> <tr>
<td>21</td>
<ttcol>SNP</ttcol> <td>IP Algorithm</td>
<td>RFC 9502, <xref target="OSPF-ALG_TLV"/></td>
<ttcol>Purge</ttcol> </tr>
</tbody>
<ttcol>Reference</ttcol> </table>
<t>This document also updates the "IS-IS Sub-TLVs for IS-IS Router CAPABIL
<c>126</c> ITY TLV"
<c>IPv4 Algorithm Prefix Reachability</c>
<c>N</c>
<c>Y</c>
<c>N</c>
<c>N</c>
<c>This document, <xref target="IS-IS-IPV4_PFX_TLV"/></c>
<c>127</c>
<c>IPv6 Algorithm Prefix Reachability</c>
<c>N</c>
<c>Y</c>
<c>N</c>
<c>N</c>
<c>This document, <xref target="IS-IS-IPV6_PFX_TLV"/></c>
</texttable>
<t>Since the above TLVs share the sub-TLV space managed in the "IS-IS
Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA is
requested to add "IPv4 Algorithm Prefix Reachability TLV (126)" and
"IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in
the description of that registry.</t>
<t>In addition, columns headed '126' and '127' are added to that registry,
as follows:</t>
<t><figure>
<artwork><![CDATA[
Type Description 126 127
---- ---------------------------------- --- ---
1 32-bit Administrative Tag Sub-TLV y y
2 64-bit Administrative Tag Sub-TLV y y
3 Prefix Segment Identifier n n
4 Prefix Attribute Flags y y
5 SRv6 End SID n n
6 Flex-Algorithm Prefix Metric n n
11 IPv4 Source Router ID y y
12 IPv6 Source Router ID y y
32 BIER Info n n
]]></artwork>
</figure></t>
<t>This document updates the "OSPFv2 Extended Prefix TLV Sub-TLVs"
registry as follows:</t> registry as follows:</t>
<table anchor="T2">
<t/> <thead>
<tr>
<texttable anchor="T4"> <th>Value</th>
<ttcol>Value</ttcol> <th>TLV Name</th>
<th>Reference</th>
<ttcol>TLV Name</ttcol> </tr>
</thead>
<ttcol>Reference</ttcol> <tbody>
<tr>
<c>TBD2</c> <td>29</td>
<td>IP Algorithm</td>
<c>OSPFv2 IP Algorithm Prefix Reachability</c> <td>RFC 9502, <xref target="IS-IS-ALG_TLV"/></td>
</tr>
<c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c> </tbody>
</table>
<c>TBD4</c> <t>This document also updates the "IS-IS Top-Level TLV Codepoints"
<c>OSPFv2 IP Forwarding Address</c>
<c>This Document, <xref target="OSPFV2_FA-SUBTLV"/></c>
</texttable>
<t>This document creates a new registry under "Open Shortest Path First v2
(OSPFv2)
Parameters" registry, called "IP Algorithm Prefix Reachability Sub-TLV Fl
ags". The
new registry defines the bits in the 8-bit Flags field in the OSPFv2 IP Al
gorithm
Prefix Reachability Sub-TLV (<xref target="OSPF-IPV4_PFX_TLV"/>). New bits
can
be allocated via IETF Review or IESG Approval <xref target="RFC8126"/></t>
<texttable anchor="T5">
<ttcol>Bit #</ttcol>
<ttcol>Name</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>bit E</c>
<c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c>
<c>1-7</c>
<c>Reserved</c>
<c>This Document, <xref target="OSPF-IPV4_PFX_TLV"/></c>
</texttable>
<t>This document updates the "OSPFv3 Extended-LSA Sub-TLVs" registry as
follows:</t>
<t/>
<texttable anchor="T6">
<ttcol>Value</ttcol>
<ttcol>TLV Name</ttcol>
<ttcol>Reference</ttcol>
<c>TBD3</c>
<c>OSPFv3 IP Algorithm Prefix Reachability</c>
<c>This Document, <xref target="OSPFV3_ALGTLV"/></c>
<c>TBD5</c>
<c>OSPFv3 IP Flexible Algorithm ASBR Metric</c>
<c>This Document, <xref target="IPFAAL"/></c>
</texttable>
<t>This document updates the "OSPFv2 Extended Inter-Area ASBR Sub-TLVs"
registry as follows:</t> registry as follows:</t>
<t/> <table anchor="T3">
<thead>
<texttable anchor="T7"> <tr>
<ttcol>Value</ttcol> <th>Value</th>
<th>TLV Name</th>
<ttcol>TLV Name</ttcol> <th>IIH</th>
<th>LSP</th>
<th>SNP</th>
<th>Purge</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>126</td>
<td>IPv4 Algorithm Prefix Reachability</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9502, <xref target="IS-IS-IPV4_PFX_TLV"/></td>
</tr>
<tr>
<td>127</td>
<td>IPv6 Algorithm Prefix Reachability</td>
<td>n</td>
<td>y</td>
<td>n</td>
<td>n</td>
<td>RFC 9502, <xref target="IS-IS-IPV6_PFX_TLV"/></td>
</tr>
</tbody>
</table>
<t>Since the above TLVs share the sub-TLV space managed in the "IS-IS
Sub-TLVs for TLVs Advertising Prefix Reachability" registry, IANA has
added "IPv4 Algorithm Prefix Reachability TLV (126)" and
"IPv6 Algorithm Prefix Reachability TLV (127)" to the list of TLVs in
the description of that registry.</t>
<t>In addition, columns headed "126" and "127" have been added to that
registry, as follows:</t>
<ttcol>Reference</ttcol> <table anchor="attribute126-127" align="center">
<name></name>
<thead>
<tr>
<th>Type</th>
<th>Description</th>
<th>126</th>
<th>127</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td>32-bit Administrative Tag Sub-TLV</td>
<td>y</td>
<td>y</td>
</tr>
<tr>
<td>2</td>
<td>64-bit Administrative Tag Sub-TLV</td>
<td>y</td>
<td>y</td>
</tr>
<tr>
<td>3</td>
<td>Prefix Segment Identifier</td>
<td>n</td>
<td>n</td>
</tr>
<tr>
<td>4</td>
<td>Prefix Attribute Flags</td>
<td>y</td>
<td>y</td>
</tr>
<tr>
<td>5</td>
<td>SRv6 End SID</td>
<td>n</td>
<td>n</td>
</tr>
<tr>
<td>6</td>
<td>Flexible Algorithm Prefix Metric (FAPM)</td>
<td>n</td>
<td>n</td>
</tr>
<tr>
<td>11</td>
<td>IPv4 Source Router ID</td>
<td>y</td>
<td>y</td>
</tr>
<tr>
<td>12</td>
<td>IPv6 Source Router ID</td>
<td>y</td>
<td>y</td>
</tr>
<tr>
<td>32</td>
<td>BIER Info</td>
<td>n</td>
<td>n</td>
</tr>
</tbody>
</table>
<c>2</c> <t>This document registers the following in the "OSPFv2 Extended Prefix TL V Sub-TLVs" registry:</t>
<c>OSPF IP Flexible Algorithm ASBR Metric</c> <table anchor="T4">
<thead>
<tr>
<th>Value</th>
<th>TLV Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>6</td>
<td>OSPFv2 IP Algorithm Prefix Reachability</td>
<td>RFC 9502, <xref target="OSPF-IPV4_PFX_TLV"/></td>
</tr>
<tr>
<td>7</td>
<td>OSPFv2 IP Forwarding Address</td>
<td>RFC 9502, <xref target="OSPFV2_FA-SUBTLV"/></td>
</tr>
</tbody>
</table>
<t>IANA has created the "IP Algorithm Prefix Reachability Sub-TLV Flags" r
egistry within the "Open Shortest Path First v2 (OSPFv2) Parameters" group of re
gistries. The new registry defines the bits in the
8-bit Flags field in the OSPFv2 IP Algorithm Prefix Reachability Sub-TLV
(<xref target="OSPF-IPV4_PFX_TLV"/>). New bits can be allocated via IETF
Review or IESG Approval <xref target="RFC8126"/></t>
<table anchor="T5">
<thead>
<tr>
<th>Bit</th>
<th>Name</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>E bit</td>
<td>RFC 9502, <xref target="OSPF-IPV4_PFX_TLV"/></td>
</tr>
<tr>
<td>1-7</td>
<td>Unassigned</td>
<td></td>
</tr>
</tbody>
</table>
<t>This document registers the following in the "OSPFv3 Extended-LSA Sub-T
LVs" registry:
</t>
<table anchor="T6">
<thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>L2BM</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>35</td>
<td>OSPFv3 IP Algorithm Prefix Reachability</td>
<td>X</td>
<td>RFC 9502, <xref target="OSPFV3_ALGTLV"/></td>
</tr>
<tr>
<td>36</td>
<td>OSPFv3 IP Flexible Algorithm ASBR Metric</td>
<td>X</td>
<td>RFC 9502, <xref target="IPFAAL"/></td>
</tr>
</tbody>
</table>
<t>This document registers the following in the "OSPFv2 Extended Inter-Are
a ASBR Sub-TLVs"
registry:</t>
<c>This Document, <xref target="IPFAAL"/></c> <table anchor="T7">
</texttable> <thead>
<tr>
<th>Value</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td>2</td>
<td>OSPF IP Flexible Algorithm ASBR Metric</td>
<td>RFC 9502, <xref target="IPFAAL"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="Security">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>This document inherits security considerations from <xref <t>This document inherits security considerations from <xref
target="RFC9350"/>.</t> target="RFC9350"/>.</t>
<t>This document adds one new way to disrupt IGP networks that are using <t>This document adds one new way to disrupt IGP networks that are using
Flex-Algorithm: an attacker can suppress reachability for a given Flexible Algorithm: an attacker can suppress reachability for a given pref
prefix whose reachability is advertised by a legitimate node for a ix
particular IP Flex-Algorithm X, by advertising the same prefix in whose reachability is advertised by a legitimate node for a particular
Flex-Algorithm Y from another, malicious node. (To see why this is, IP Flex-Algorithm X by advertising the same prefix in Flex-Algorithm Y
consider, for example, the rule given in the second-last paragraph of from another malicious node. (To see why this is, consider, for
<xref target="IS-IS-IPV4_PFX_TLV"/>).</t> example, the rule given in the second-to-last paragraph of <xref
target="IS-IS-IPV4_PFX_TLV"/>).</t>
<t>This attack can be addressed by the existing security extensions, as <t>This attack can be addressed by the existing security extensions, as
described in <xref target="RFC5304"/> and <xref target="RFC5310"/> for described in <xref target="RFC5304"/> and <xref target="RFC5310"/> for
IS-IS, IS-IS, in <xref target="RFC2328"/> and <xref target="RFC7474"/> for
in <xref target="RFC2328"/> and <xref target="RFC7474"/>for OSPFv2, and OSPFv2, and in <xref target="RFC4552"/> and <xref target="RFC5340"/> for
in OSPFv3.</t>
<xref target="RFC4552"/> and <xref target="RFC5340"/> for OSPFv3.</t> <t>If a node that is authenticated is taken over by an attacker, such a
rogue node can perform the attack described above. Such an attack is
<t>If a node that is authenticated is taken over by an attacker, such a not preventable through authentication, and it is not different from
rogue node can perform the attack described above. Such an attack is advertising any other incorrect information through IS-IS or OSPF.</t>
not preventable through authentication, and it is not different from
advertising any other incorrect information through IS-IS or OSPF.</t>
</section> </section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Bruno Decraene for his contributions to this document.
Special thanks to Petr Bonbon Adamec of Cesnet for supporting
interoperability testing.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include='reference.RFC.2119'?> <name>References</name>
<references>
<?rfc include='reference.RFC.2328'?> <name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.4552'?> 119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<?rfc include='reference.RFC.5120'?> 328.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include='reference.RFC.5304'?> 552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.5308'?> 120.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.5310'?> 304.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.5340'?> 308.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include='reference.RFC.8174'?> 310.xml"/>
<?rfc include='reference.RFC.4915'?>
<?rfc include='reference.RFC.7770'?>
<?rfc include='reference.RFC.7474'?>
<?rfc include='reference.RFC.7981'?>
<?rfc include='reference.RFC.9350'?> <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340">
<front>
<title>OSPF for IPv6</title>
<author fullname="R. Coltun" initials="R." surname="Coltun"/>
<author fullname="D. Ferguson" initials="D." surname="Ferguson"/>
<author fullname="J. Moy" initials="J." surname="Moy"/>
<author fullname="A. Lindem" initials="A." surname="Lindem" role="editor"/>
<date month="July" year="2008"/>
</front>
<seriesInfo name="RFC" value="5340"/>
<seriesInfo name="DOI" value="10.17487/RFC5340"/>
</reference>
<?rfc include='reference.RFC.9352'?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
915.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
770.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
474.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
981.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"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
362.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
305.xml"/>
<?rfc include='reference.RFC.8362'?> <reference anchor="ISO10589">
<front>
<title>Information technology - Telecommunications and information e
xchange between systems - Intermediate System to Intermediate System intra-domai
n routeing information exchange protocol for use in conjunction with the protoco
l for providing the connectionless-mode network service (ISO 8473)</title>
<author>
<organization abbrev="ISO">International Organization for
Standardization</organization>
</author>
<date month="November" year="2002"/>
</front>
<seriesInfo name="ISO/IEC" value="10589:2002"/>
<refcontent>Second Edition</refcontent>
</reference>
</references>
<?fc include='reference.RFC.5305'?> <references>
<name>Informative References</name>
<reference anchor="ISO10589" target="ISO/IEC 10589:2002"> <reference anchor="TS.23.501-3GPP">
<front> <front>
<title>Intermediate system to Intermediate system routing <title>System architecture for 5G System (5GS)</title>
information exchange protocol for use in conjunction with the <author>
Protocol for providing the Connectionless-mode Network Service (ISO <organization>3GPP</organization>
8473)</title> </author>
<date month="September" year="2023"/>
</front>
<seriesInfo name="3GPP TS" value="23.501"/>
<refcontent>Release 18.3.0</refcontent>
</reference>
<author> <reference anchor="IANA-ALG" target="https://www.iana.org/assignments/ig
<organization abbrev="ISO">International Organization for p-parameters">
Standardization</organization> <front>
</author> <title>IGP Algorithm Types</title>
<author fullname="" initials="" surname="">
<organization>IANA</organization>
</author>
</front>
</reference>
<date month="Nov" year="2002"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</front> 402.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
286.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
490.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
986.xml"/>
</references>
</references> </references>
<references title="Informative References"> <section anchor="Acknowledgements" numbered="false" toc="default">
<reference anchor='TS.23.501-3GPP'> <name>Acknowledgements</name>
<front> <t>Thanks to <contact fullname="Bruno Decraene"/> for his contributions
<title>System Architecture for 5G System; Stage 2, 3GPP TS 23.501 v16.4. to this document. Special thanks to <contact fullname="Petr Bonbon
0</title> Adamec"/> of Cesnet for supporting interoperability testing.</t>
<author> </section>
<organization>
3rd Generation Partnership Project (3GPP)
</organization>
</author>
<date month="March" year="2020"/>
</front>
</reference>
<reference anchor="IANA-ALG"
target="https://www.iana.org/assignments/igp-parameters/igp-par
ameters.xhtml#igp-algorithm-types">
<front>
<title>IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV</title>
<author fullname="" initials="" surname="">
<organization>IANA</organization>
</author>
<date month="August" year="1987"/>
</front>
</reference>
<?rfc include='reference.RFC.8402'?>
<?rfc include='reference.RFC.8126'?>
<?rfc include='reference.RFC.5286'?>
<?rfc include='reference.RFC.7490'?>
<?rfc include='reference.RFC.8986'?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 160 change blocks. 
1073 lines changed or deleted 960 lines changed or added

This html diff was produced by rfcdiff 1.48.