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 " "> | |||
<?rfc tocindent="yes"?> | <!ENTITY zwsp "​"> | |||
<?rfc symrefs="yes"?> | <!ENTITY nbhy "‑"> | |||
<?rfc sortrefs="yes"?> | <!ENTITY wj "⁠"> | |||
<?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 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. |