rfc9084xml2.original.xml   rfc9084.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-lsr-ospf-pre
RFC.2119.xml"> fix-originator-12" number="9084" ipr="trust200902" obsoletes="" updates="" submi
]> ssionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"
<?rfc toc="yes"?> tocDepth="3" symRefs="true" sortRefs="true" version="3">
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-lsr-ospf-prefix-originator-12"
ipr="trust200902">
<front> <front>
<title abbrev="OSPF Prefix Originator Extensions">OSPF Prefix Originator <title abbrev="OSPF Prefix Originator Extensions">OSPF Prefix Originator
Extensions</title> Extensions</title>
<seriesInfo name="RFC" value="9084"/>
<author fullname="Aijun Wang" initials="A" surname="Wang"> <author fullname="Aijun Wang" initials="A" surname="Wang">
<organization>China Telecom</organization> <organization>China Telecom</organization>
<address> <address>
<postal> <postal>
<street>Beiqijia Town, Changping District</street> <extaddr>Beiqijia Town</extaddr>
<street>Changping District</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code>102209</code> <code>102209</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>wangaj3@chinatelecom.cn</email> <email>wangaj3@chinatelecom.cn</email>
</address> </address>
</author> </author>
<author fullname="Acee Lindem" initials="A" surname="Lindem"> <author fullname="Acee Lindem" initials="A" surname="Lindem">
<organization>Cisco Systems</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>301 Midenhall Way</street> <street>301 Midenhall Way</street>
<city>Cary</city> <city>Cary</city>
<region>NC</region> <region>NC</region>
<code>27513</code> <code>27513</code>
<country>United States of America</country>
<country>USA</country>
</postal> </postal>
<email>acee@cisco.com</email> <email>acee@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Jie Dong" initials="J" surname="Dong"> <author fullname="Jie Dong" initials="J." surname="Dong">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street/> <street>Huawei Campus, No. 156 Beiqing Rd.</street>
<city>Beijing</city> <city>Beijing</city>
<region/> <region/>
<code>100095</code>
<code/>
<country>China</country> <country>China</country>
</postal> </postal>
<email>jie.dong@huawei.com</email> <email>jie.dong@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Peter Psenak" initials="P" surname="Psenak"> <author fullname="Peter Psenak" initials="P" surname="Psenak">
<organization>Cisco Systems</organization> <organization>Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>Pribinova Street 10</street> <street>Pribinova Street 10</street>
<city>Bratislava</city> <city>Bratislava</city>
<extaddr>Eurovea Centre, Central 3</extaddr>
<region>Eurovea Centre, Central 3</region>
<code>81109</code> <code>81109</code>
<country>Slovakia</country> <country>Slovakia</country>
</postal> </postal>
<phone/> <phone/>
<facsimile/>
<email>ppsenak@cisco.com</email> <email>ppsenak@cisco.com</email>
<uri/> <uri/>
</address> </address>
</author> </author>
<author fullname="Ketan Talaulikar" initials="K" role="editor" surname="Tala
<author fullname="Ketan Talaulikar" initials="K" role="editor" ulikar">
surname="Talaulikar"> <organization>Cisco Systems, Inc.</organization>
<organization>Cisco Systems</organization>
<address> <address>
<postal> <postal>
<street/> <street/>
<city/> <city/>
<region/> <region/>
<code/> <code/>
<country>India</country> <country>India</country>
</postal> </postal>
<email>ketant@cisco.com</email> <email>ketant@cisco.com</email>
</address> </address>
</author> </author>
<date year="2021" month="August" />
<date year=""/> <area>RTG</area>
<workgroup>LSR</workgroup>
<area>RTG Area</area>
<workgroup>LSR Working Group</workgroup>
<keyword>OSPF</keyword> <keyword>OSPF</keyword>
<abstract> <abstract>
<t>This document defines OSPF extensions to include information <t>This document defines OSPF extensions to include information
associated with the node originating a prefix along with the prefix associated with the node originating a prefix along with the prefix
advertisement. These extensions do not change the core OSPF route advertisement. These extensions do not change the core OSPF route
computation functionality but provide useful information for network computation functionality but provide useful information for network
analysis, troubleshooting, and use-cases like traffic engineering.</t> analysis, troubleshooting, and use cases like traffic engineering.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>Prefix attributes are advertised in OSPFv2 <xref target="RFC2328"/> <name>Introduction</name>
using the Extended Prefix Opaque Link State Advertisement (LSA) <xref <t>Prefix attributes are advertised in OSPFv2 <xref target="RFC2328" forma
target="RFC7684"/> and in OSPFv3 <xref target="RFC5340"/> using the t="default"/>
various Extended Prefix LSA types <xref target="RFC8362"/>.</t> using the Extended Prefix Opaque Link State Advertisement (LSA) <xref targ
et="RFC7684" format="default"/> and in OSPFv3 <xref target="RFC5340" format="def
ault"/> using the
various Extended Prefix LSA types <xref target="RFC8362" format="default"/
>.</t>
<t>The procedures for identification of the originating router for a <t>The procedures for identification of the originating router for a
prefix in OSPF vary by the type of the prefix and, currently, it is not prefix in OSPF vary by the type of the prefix and, currently, it is not
always possible to produce an accurate result. For intra-area prefixes, always possible to produce an accurate result. For intra-area prefixes,
the originating router is identified by the Advertising Router field of the originating router is identified by the Advertising Router field of
the area-scoped LSA used for those prefix advertisements. However, for the area-scoped LSA used for those prefix advertisements. However, for
the inter-area prefixes advertised by the Area Border Router (ABR), the inter-area prefixes advertised by an Area Border Router (ABR), the
Advertising Router field of their area-scoped LSAs is set to the ABR Advertising Router field of their area-scoped LSAs is set to the ABR
itself and the information about the router originating the prefix itself and the information about the router originating the prefix
advertisement is lost in this process of prefix propagation across advertisement is lost in the process of prefix propagation across
areas. For Autonomous System (AS) external prefixes, the originating areas. For Autonomous System (AS) external prefixes, the originating
router may be considered as the Autonomous System Border Router (ASBR) router may be considered as the Autonomous System Border Router (ASBR)
and is identified by the Advertising Router field of the AS-scoped LSA and is identified by the Advertising Router field of the AS-scoped LSA
used. However, the actual originating router for the prefix may be a used. However, the actual originating router for the prefix may be a
remote router outside the OSPF domain. Similarly, when an ABR performs remote router outside the OSPF domain. Similarly, when an ABR performs
translation of Not-So-Stubby Area (NSSA) <xref target="RFC3101"/> LSAs translation of Not-So-Stubby Area (NSSA) <xref target="RFC3101"
to AS-external LSAs, the information associated with the NSSA ASBR (or format="default"/> LSAs to AS-external LSAs, the information associated
the router outside the OSPF domain) is not conveyed across the OSPF with the NSSA ASBR (or the router outside the OSPF domain) is not
domain.</t> propagated across the OSPF domain.</t>
<t>While typically the originator of information in OSPF is identified <t>While typically the originator of information in OSPF is identified
by its OSPF Router ID, it does not necessarily represent a reachable by its OSPF Router ID, it does not necessarily represent a reachable
address for the router since the OSPF Router ID is a 32-bit number. address for the router since the OSPF Router ID is a 32-bit number that
There exists a prevalent practice to use one of the IPv4 address of the is unique in the OSPF domain. For OSPFv2, a common practice is to use
node (e.g. a loopback interface) as an OSPF Router ID in the case of one of the IPv4 addresses of the node (e.g., a loopback interface) as
OSPFv2. However, this cannot be always assumed and this approach does the OSPF Router ID. However, this cannot always be assumed and this
not extend to IPv6 addresses with OSPFv3. The IPv4/IPv6 Router Address approach does not apply to IPv6 addresses with OSPFv3. The IPv4/IPv6
as defined in <xref target="RFC3630"/> and <xref target="RFC5329"/> for Router Address, as respectively defined in <xref target="RFC3630"
OSPFv2 and OSPFv3 respectively provide an address to reach that format="default"/> and <xref target="RFC5329" format="default"/> for
OSPFv2 and OSPFv3, provides an address to reach the advertising
router.</t> router.</t>
<t>The primary use case for the extensions proposed in this document is <t>The primary use case for the extensions proposed in this document is
to be able to identify the originator of a prefix in the network. In to be able to identify the originator of a prefix in the network. In
cases where multiple prefixes are advertised by a given router, it is cases where multiple prefixes are advertised by a given router, it is
also useful to be able to associate all these prefixes with a single also useful to be able to associate all these prefixes with a single
router even when prefixes are advertised outside of the area in which router even when prefixes are advertised outside of the area in which
they originated. It also helps to determine when the same prefix is they originated. It also helps to determine when the same prefix is
being originated by multiple routers across areas.</t> being originated by multiple routers across areas.</t>
<t>This document proposes extensions to the OSPF protocol for the <t>This document proposes extensions to the OSPF protocol for the
inclusion of information associated with the router originating the inclusion of information associated with the router originating the
prefix along with the prefix advertisement. These extensions do not prefix along with the prefix advertisement. These extensions do not
change the core OSPF route computation functionality. They provide change the core OSPF route computation functionality. They provide
useful information for topology analysis and traffic engineering, useful information for topology analysis and traffic engineering,
especially on a controller when this information is advertised as an especially on a controller when this information is advertised as an
attribute of the prefixes via mechanisms such as Border Gateway Protocol attribute of the prefixes via mechanisms such as Border Gateway Protocol
Link-State (BGP-LS) <xref target="RFC7752"/> <xref - Link State (BGP-LS) <xref target="RFC7752" format="default"/> <xref
target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>.</t> target="RFC9085" format="default"/>.</t>
<section anchor="reqlang" numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="reqlang" title="Requirements Language"> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
when, they appear in all capitals, as shown here.</t> are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119" format="default"/> <xref target="RFC8174"
format="default"/> when, and only when, they appear in all capitals,
as shown here.</t>
</section> </section>
</section> </section>
<section anchor="extensions." numbered="true" toc="default">
<section anchor="extensions." title="Protocol Extensions"> <name>Protocol Extensions</name>
<t>This document defines the Prefix Source OSPF Router-ID and the Prefix <t>This document defines the Prefix Source OSPF Router-ID and the Prefix
Source Router Address Sub-TLVs. They are used, respectively, to include Source Router Address Sub-TLVs. They are used, respectively, to include
the Router ID of, and a reachable address of, the router that originates the Router ID of, and a reachable address of, the router that originates
the prefix as a prefix attribute.</t> the prefix as a prefix attribute.</t>
<section anchor="SrcRtrTLV" numbered="true" toc="default">
<section anchor="SrcRtrTLV" title="Prefix Source OSPF Router-ID Sub-TLV"> <name>Prefix Source OSPF Router-ID Sub-TLV</name>
<t>For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional <t>For OSPFv2, the Prefix Source OSPF Router-ID Sub-TLV is an optional
Sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684"/>. sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684" format= "default"/>.
For OSPFv3, the Prefix Source OSPF Router-ID Sub-TLV is an optional For OSPFv3, the Prefix Source OSPF Router-ID Sub-TLV is an optional
Sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and
External-Prefix TLV <xref target="RFC8362"/> when originating either External-Prefix TLV <xref target="RFC8362" format="default"/> when origi
an IPv4 <xref target="RFC5838"/> or an IPv6 prefix advertisement.</t> nating either
an IPv4 <xref target="RFC5838" format="default"/> or an IPv6 prefix adve
rtisement.</t>
<t>The Prefix Source OSPF Router-ID Sub-TLV has the following <t>The Prefix Source OSPF Router-ID Sub-TLV has the following
format:</t> format:</t>
<figure title="Prefix Source OSPF Router-ID Sub-TLV Format">
<figure> <artwork name="" type="" align="left" alt=""><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Router ID | | OSPF Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 1: Prefix Source OSPF Router-ID Sub-TLV Format <dl newline="true">
<dt>Where:
</dt>
Where: ]]></artwork> <dd>
</figure> <dl>
<t><list style="symbols"> <dt>Type:</dt>
<t>Type: 4 for OSPFv2 and 27 for OSPFv3</t> <dd>4 for OSPFv2 and 27 for OSPFv3</dd>
<t>Length: 4</t> <dt>Length:</dt>
<dd>4</dd>
<t>OSPF Router ID : the OSPF Router ID of the OSPF router that <dt>OSPF Router ID:
originated the prefix advertisement in the OSPF domain.</t> </dt>
</list></t> <dd>the OSPF Router ID of the OSPF router that originated the prefix
advertisement in the OSPF domain
</dd>
<t>The parent TLV of a prefix advertisement MAY include more than one </dl>
Prefix Source OSPF Router-ID sub-TLV, one corresponding to each of the
Equal-Cost Multi-Path (ECMP) nodes that originated the given
prefix.</t>
</dd>
</dl>
<t>The parent TLV of a prefix advertisement <bcp14>MAY</bcp14> include
more than one Prefix Source OSPF Router-ID Sub-TLV, one corresponding
to each of the Equal-Cost Multipath (ECMP) nodes that originated the
advertised prefix.</t>
<t>For intra-area prefix advertisements, the Prefix Source OSPF <t>For intra-area prefix advertisements, the Prefix Source OSPF
Router-ID Sub-TLV MUST be considered invalid and ignored if the OSPF Router-ID Sub-TLV <bcp14>MUST</bcp14> be considered invalid and ignored if the OSPF
Router ID field is not the same as the Advertising Router field in the Router ID field is not the same as the Advertising Router field in the
containing LSA. Similar validation cannot be reliably performed for containing LSA. Similar validation cannot be reliably performed for
inter-area and external prefix advertisements.</t> inter-area and external prefix advertisements.</t>
<t>A received Prefix Source OSPF Router-ID Sub-TLV with the OSPF
<t>A received Prefix Source OSPF Router-ID Sub-TLV with OSPF Router ID Router ID field set to 0 <bcp14>MUST</bcp14> be considered invalid and
set to 0 MUST be considered invalid and ignored. Additionally, ignored. Additionally, reception of such sub-TLVs
reception of such Sub-TLV SHOULD be logged as an error (subject to <bcp14>SHOULD</bcp14> be logged as an error (subject to rate
rate-limiting).</t> limiting).</t>
</section> </section>
<section anchor="POTLV" numbered="true" toc="default">
<section anchor="POTLV" title="Prefix Source Router Address Sub-TLV"> <name>Prefix Source Router Address Sub-TLV</name>
<t>For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional <t>For OSPFv2, the Prefix Source Router Address Sub-TLV is an optional
Sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684"/>. sub-TLV of the OSPFv2 Extended Prefix TLV <xref target="RFC7684" format= "default"/>.
For OSPFv3, the Prefix Source Router Address Sub-TLV is an optional For OSPFv3, the Prefix Source Router Address Sub-TLV is an optional
Sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and sub-TLV of the Intra-Area-Prefix TLV, Inter-Area-Prefix TLV, and
External-Prefix TLV <xref target="RFC8362"/> when originating either External-Prefix TLV <xref target="RFC8362" format="default"/> when origi
an IPv4 <xref target="RFC5838"/> or an IPv6 prefix advertisement.</t> nating either
an IPv4 <xref target="RFC5838" format="default"/> or an IPv6 prefix adve
rtisement.</t>
<t>The Prefix Source Router Address Sub-TLV has the following <t>The Prefix Source Router Address Sub-TLV has the following
format:</t> format:</t>
<figure title="Prefix Source Router Address Sub-TLV Format">
<figure> <artwork name="" type="" align="left" alt=""><![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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Address (4 or 16 octets) | | Router Address (4 or 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
Figure 2: Prefix Source Router Address Sub-TLV Format <dl newline="true">
Where: ]]></artwork> <dt>Where:
</figure> </dt>
<dd>
<t><list style="symbols"> <dl>
<t>Type: 5 (suggested) for OSPFv2 and 28 (suggested) for
OSPFv3</t>
<t>Length: 4 or 16</t> <dt>Type:
</dt>
<dd>5 for OSPFv2 and 28 for OSPFv3
</dd>
<t>Router Address: A reachable IPv4 or IPv6 router address for the <dt>Length:
router that originated the IPv4 or IPv6 prefix advertisement </dt>
respectively. Such an address would be semantically equivalent to <dd>4 or 16
what may be advertised in the OSPFv2 Router Address TLV <xref </dd>
target="RFC3630"/> or in the OSPFv3 Router IPv6 Address TLV <xref
target="RFC5329"/>.</t>
</list></t>
<t>The parent TLV of a prefix advertisement MAY include more than one <dt>Router Address:
Prefix Source Router Address Sub-TLV, one corresponding to each of the </dt>
Equal-Cost Multi-Path (ECMP) nodes that originated the given <dd>A reachable IPv4 or IPv6 router address for the router that originated the
prefix.</t> IPv4 or IPv6 prefix advertisement, respectively. Such an address would be
semantically equivalent to what may be advertised in the OSPFv2 Router Address
TLV <xref target="RFC3630" format="default"/> or in the OSPFv3 Router IPv6
Address TLV <xref target="RFC5329" format="default"/>.
</dd>
</dl>
</dd>
</dl>
<t>The parent TLV of a prefix advertisement <bcp14>MAY</bcp14> include
more than one Prefix Source Router Address Sub-TLV, one corresponding to
each of the Equal-Cost Multipath (ECMP) nodes that originated the
advertised prefix.</t>
<t>A received Prefix Source Router Address Sub-TLV that has an invalid <t>A received Prefix Source Router Address Sub-TLV that has an invalid
length (i.e. not consistent with the prefix's address family) MUST be length (i.e., not consistent with the prefix's address family)
considered invalid and ignored. Additionally, reception of such <bcp14>MUST</bcp14> be considered invalid and ignored. Additionally,
Sub-TLV SHOULD be logged as an error (subject to rate-limiting).</t> reception of such sub-TLVs <bcp14>SHOULD</bcp14> be logged as an
error (subject to rate limiting).</t>
</section> </section>
</section> </section>
<section anchor="procedures" title="Elements of Procedure"> <section anchor="procedures" numbered="true" toc="default">
<name>Elements of Procedure</name>
<t>This section describes the procedure for the advertisement of the <t>This section describes the procedure for the advertisement of the
Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs Prefix Source OSPF Router-ID and Prefix Source Router Address Sub-TLVs
along with the prefix advertisement.</t> along with the prefix advertisement.</t>
<t>The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the <t>The OSPF Router ID of the Prefix Source OSPF Router-ID is set to the
OSPF Router ID of the node originating the prefix in the OSPF OSPF Router ID of the node originating the prefix in the OSPF
domain.</t> domain.</t>
<t>If the originating node is advertising an OSPFv2 Router Address TLV <t>If the originating node is advertising an OSPFv2 Router Address TLV
<xref target="RFC3630"/> or an OSPFv3 Router IPv6 Address TLV <xref <xref target="RFC3630" format="default"/> or an OSPFv3 Router IPv6
target="RFC5329"/>, then the same address MUST be used in the Router Address TLV <xref target="RFC5329" format="default"/>, then the same
Address field of the Prefix Source Router Address Sub-TLV. When the address <bcp14>MUST</bcp14> be used in the Router Address field of the
originating node is not advertising such an address, implementations can Prefix Source Router Address Sub-TLV. When the originating node is not
determine a unique and reachable address (for example, advertised with advertising such an address, implementations can select a unique and
the N-flag set <xref target="RFC7684"/> or N-bit set <xref reachable local address (for example, advertised with the N-Flag set
target="RFC8362"/>) belonging to the originating node to set in the <xref target="RFC7684" format="default"/> or N-bit set <xref
Router Address field.</t> target="RFC8362" format="default"/>) on the originating node to
advertise in the Router Address field.</t>
<t>When an ABR generates inter-area prefix advertisements into its <t>When an ABR generates inter-area prefix advertisements into its
non-backbone areas corresponding to an inter-area prefix advertisement non-backbone areas corresponding to an inter-area prefix advertisement
from the backbone area, the only way to determine the originating node from the backbone area, the only way to determine the originating node
information is based on the Prefix Source OSPF Router-ID and Prefix information is based on the Prefix Source OSPF Router-ID and Prefix
Source Router Address Sub-TLVs present in the inter-area prefix Source Router Address Sub-TLVs present in the inter-area prefix
advertisement originated into the backbone area by an ABR from another advertisement originated into the backbone area by an ABR from another
non-backbone area. The ABR performs its prefix calculation to determine non-backbone area. The ABR performs its prefix calculation to determine
the set of nodes that contribute to the best prefix reachability. It the set of nodes that contribute to ECMP paths for the prefix. It
MUST use the prefix originator information only from this set of nodes. <bcp14>MUST</bcp14> only use the prefix originator information from this
The ABR MUST NOT include the Prefix Source OSPF Router-ID or the Prefix set of nodes. The ABR <bcp14>MUST NOT</bcp14> include the Prefix Source
Source Router Address Sub-TLVs when it is unable to determine the OSPF Router-ID or the Prefix Source Router Address Sub-TLVs when it is
information of the best originating nodes.</t> unable to determine the information for the originating nodes
contributing ECMP paths.</t>
<t>Implementations may support the propagation of the originating node <t>Implementations may support the propagation of the originating node
information along with a redistributed prefix into the OSPF domain from information along with a redistributed prefix into the OSPF domain from
another routing domain. The details of such mechanisms are outside the another routing domain. The details of such mechanisms are outside the
scope of this document. Such implementations may also provide control on scope of this document. Such implementations may also provide control on
whether the Router Address in the Prefix Source Router Address Sub-TLV whether the Router Address in the Prefix Source Router Address Sub-TLV
is set as the ABSR node address or as the address of the actual node is set as the ASBR node address or as the address of the actual node
outside the OSPF domain that owns the prefix.</t> outside the OSPF domain that owns the prefix.</t>
<t>When translating the NSSA prefix advertisements <xref <t>When translating NSSA prefix advertisements <xref target="RFC3101"
target="RFC3101"/> to the AS external prefix advertisements, the NSSA format="default"/> to AS external prefix advertisements, the NSSA ABR
ABR, follows the same procedures as an ABR generating inter-area prefix follows the same procedures as an ABR generating inter-area prefix
advertisements for the propagation of the originating node advertisements for the propagation of the originating node
information.</t> information.</t>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>Since this document extends the OSPFv2 Extended Prefix LSA, the <t>Since this document extends the OSPFv2 Extended Prefix LSA, the
security considerations for <xref target="RFC7684"/> are applicable. security considerations for <xref target="RFC7684" format="default"/> are applicable.
Similarly, since this document extends the OSPFv3 Similarly, since this document extends the OSPFv3
E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External LSA, and E-Intra-Area-Prefix-LSA, E-Inter-Area-Prefix-LSA, E-AS-External-LSA, and
E-NSSA-LSA, the security considerations for <xref target="RFC8362"/> are E-NSSA-LSA, the security considerations for <xref target="RFC8362" format=
"default"/> are
applicable. The new sub-TLVs introduced in this document are optional applicable. The new sub-TLVs introduced in this document are optional
and do not affect the OSPF route computation and therefore do not affect and do not affect the OSPF route computation and therefore do not affect
the security aspects of OSPF protocol operations.</t> the security aspects of OSPF protocol operations.</t>
<t>A rogue node that can inject prefix advertisements may use the new <t>A rogue node that can inject prefix advertisements may use the
extensions introduced in this document to indicate an incorrect prefix extensions introduced in this document to advertise bogus prefix
source information.</t> source information.</t>
</section> </section>
<section anchor="operational" numbered="true" toc="default">
<section anchor="operational" title="Operational Considerations"> <name>Operational Considerations</name>
<t>Consideration should be given to the operational impact of the <t>Consideration should be given to the operational impact of the
increase in the size of the OSPF Link-State Database as a result of the increase in the size of the OSPF Link-State Database as a result of the
protocol extensions in this document. Based on deployment design and protocol extensions in this document. Based on deployment design and
requirements, a subset of prefixes may be identified for which the requirements, a subset of prefixes may be identified for which
originating node information needs to be included with their prefix originating node information is required to be included in prefix
advertisements.</t> advertisements.</t>
<t>The propagation of the prefix source node information when doing <t>The propagation of prefix source node information for prefix
prefix advertisements across OSPF area or domain boundaries results in advertisements advertised across an OSPF area or domain boundaries will
the exposure of node information outside of an area or domain within expose information outside of an area or domain where it would normally
which it is normally hidden or abstracted by the base OSPF protocol. be hidden or abstracted by the base OSPF protocol. Based on deployment
Based on deployment design and requirements, a subset of prefixes may be design and requirements, the propagation of node information across area
identified for which the propagation of the originating node information or domain boundaries may be limited to a subset of prefixes in the ABRs
across area or domain boundaries is disabled at the ABRs or ASBRs or ASBRs, respectively.
respectively.</t> </t>
<t>The identification of the node that is originating a specific prefix <t>The identification of the node that is originating a specific prefix
in the network may aid in debugging of issues related to prefix in the network may aid in the debugging of issues related to prefix
reachability within an OSPF network.</t> reachability within an OSPF network.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document requests IANA for the allocation of the codepoints from <t>Per this document, IANA has allocated the following codepoints from
the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open the "OSPFv2 Extended Prefix TLV Sub-TLVs" registry under the "Open
Shortest Path First v2 (OSPFv2) Parameters" registry.</t> Shortest Path First v2 (OSPFv2) Parameters" registry.</t>
<figure> <table anchor="extended_prefix">
<artwork><![CDATA[ <name>Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <thead>
| Code | Description | IANA Allocation | <tr>
| Point | | Status | <th>Value</th>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <th>Description</th>
| 4 | Prefix Source OSPF Router-ID | early allocation done | <th>Reference</th>
| 5 | Prefix Source Router Address | suggested | </tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </thead>
<tbody>
Figure 3: Codepoints in OSPFv2 Extended Prefix TLV Sub-TLVs <tr>
<td>4</td>
<td>Prefix Source OSPF Router-ID</td>
<td>RFC 9084</td>
</tr>
<tr>
<td>5</td>
<td>Prefix Source Router Address</td>
<td>RFC 9084</td>
</tr>
]]></artwork> </tbody>
</figure> </table>
<t>This document requests IANA for the allocation of the codepoints from <t>Per this document, IANA has allocated the following codepoints from
the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest the "OSPFv3 Extended-LSA Sub-TLVs" registry under the "Open Shortest
Path First v3 (OSPFv3) Parameters" registry.</t> Path First v3 (OSPFv3) Parameters" registry.</t>
<t><figure> <table anchor="extended_lsa">
<artwork><![CDATA[ <name>Codepoints in OSPFv3 Extended-LSA Sub-TLVs</name>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <thead>
| Code | Description | IANA Allocation | <tr>
| Point | | Status | <th>Value</th>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <th>Description</th>
| 27 | Prefix Source OSPF Router-ID | early allocation done | <th>Reference</th>
| 28 | Prefix Source Router Address | suggested | </tr>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </thead>
<tbody>
Figure 4: Codepoints in OSPFv3 Extended-LSA Sub-TLVs <tr>
<td>27</td>
<td>Prefix Source OSPF Router-ID</td>
<td>RFC 9084</td>
</tr>
<tr>
<td>28</td>
<td>Prefix Source Router Address</td>
<td>RFC 9084</td>
</tr>
]]></artwork> </tbody>
</figure></t> </table>
</section> </section>
<section anchor="ack" title="Acknowledgement">
<t>Many thanks to Les Ginsberg for his suggestions on this draft. Also
thanks to Jeff Tantsura, Rob Shakir, Gunter Van De Velde, Goethals Dirk,
Smita Selot, Shaofu Peng, John E Drake and Baalajee S for their review
and valuable comments. The authors would also like to thank Alvaro
Retana for his detailed review and suggestions for the improvement of
this document.</t>
</section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<?rfc include="reference.RFC.2119"?> <name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2328.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3630.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5340.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7684.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5329.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8362.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3101.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<?rfc include="reference.RFC.2328"?> <reference anchor='RFC9085' target='https://www.rfc-editor.org/info/rfc9085'>
<front>
<title>Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment
Routing</title>
<?rfc include="reference.RFC.3630"?> <author initials='S' surname='Previdi' fullname='Stefano Previdi'>
<organization />
</author>
<?rfc include="reference.RFC.5340"?> <author initials='K' surname='Talaulikar' fullname='Ketan Talaulikar' role='
editor'>
<organization />
</author>
<?rfc include="reference.RFC.7684"?> <author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
<organization />
</author>
<?rfc include="reference.RFC.5329"?> <author initials='H' surname='Gredler' fullname='Hannes Gredler'>
<organization />
</author>
<?rfc include="reference.RFC.8174"?> <author initials='M' surname='Chen' fullname='Mach(Guoyi) Chen'>
<organization />
</author>
<?rfc include="reference.RFC.8362"?> <date month='August' year='2021' />
</references>
<references title="Informative References"> </front>
<?rfc include="reference.RFC.3101"?> <seriesInfo name="RFC" value="9085"/>
<seriesInfo name="DOI" value="10.17487/RFC9085"/>
</reference>
<?rfc include="reference.RFC.5838"?> </references>
</references>
<?rfc include="reference.RFC.7752"?> <section anchor="ack" numbered="false" toc="default">
<name>Acknowledgement</name>
<t>Many thanks to <contact fullname="Les Ginsberg"/> for his suggestions
on this document. Also, thanks to <contact fullname="Jeff Tantsura"/>,
<contact fullname="Rob Shakir"/>, <contact fullname="Gunter Van de
Velde"/>, <contact fullname="Goethals Dirk"/>, <contact fullname="Smita
Selot"/>, <contact fullname="Shaofu Peng"/>, <contact fullname="John E. Drake"/>
, and <contact fullname="Baalajee S."/> for their review and
valuable comments. The authors would also like to thank <contact
fullname="Alvaro Retana"/> for his detailed review and suggestions for
the improvement of this document.</t>
</section>
<?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml"?>
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 111 change blocks. 
266 lines changed or deleted 310 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/