<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-lsr-ospf-terminology-09" number="9454" ipr="trust200902" obsoletes="" updates="2328, 4222, 4811, 5243, 5340, 5614, 5838" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" prepTime="2023-08-16T14:13:03" indexInclude="true" scripts="Common,Latin">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-terminology-09" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9454" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="OSPF Terminology">Update to OSPF Terminology</title>
    <seriesInfo name="RFC" value="9454" stream="IETF"/>
    <author initials="M" surname="Fox" fullname="Mike Fox">
      <organization showOnFrontPage="true">IBM</organization>
      <address>
        <postal>
          <street>3039 E Cornwallis Rd.</street>
          <city>Research Triangle Park</city>
          <region>NC</region>
          <code>27709</code>
          <country>United States of America</country>
        </postal>
        <email>mjfox@us.ibm.com</email>
      </address>
    </author>
    <author initials="A" surname="Lindem" fullname="Acee Lindem">
      <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization>
      <address>
        <postal>
          <street>301 Midenhall Way</street>
          <city>Cary</city>
          <region>NC</region>
          <code>27513</code>
          <country>United States of America</country>
        </postal>
        <email>acee.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="A" surname="Retana" fullname="Alvaro Retana">
      <organization showOnFrontPage="true">Futurewei Technologies, Inc.</organization>
      <address>
        <postal>
          <street>2330 Central Expressway</street>
          <city>Santa Clara</city>
          <region>CA</region>
          <code>95050</code>
          <country>United States of America</country>
        </postal>
        <email>aretana@futurewei.com</email>
      </address>
    </author>
    <date month="08" year="2023"/>
    <area>rtg</area>
    <workgroup>lsr</workgroup>
    <keyword>OSPF terminology</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        This document updates some OSPF terminology to be in line with inclusive language used in the industry.
        The IETF has designated "Guidance for NIST Staff on Using
        Inclusive Language in Documentary Standards" by the US National Institute of Standards and Technology (NIST) 
        for its inclusive language guidelines. It is intended that all
        future OSPF documents use this revised terminology even when they reference the RFCs updated by this
        document.
      </t>
      <t indent="0" pn="section-abstract-2">
        This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and 5838.
      </t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9454" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2023 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-2328">Update to RFC 2328</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-4222">Update to RFC 4222</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-4811">Update to RFC 4811</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-5243">Update to RFC 5243</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-5340">Update to RFC 5340</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-5614">Update to RFC 5614</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-update-to-rfc-5838">Update to RFC 5838</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="11" format="counter" sectionFormat="of" target="section-11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t indent="0" pn="section-toc.1-1.11.2.1.1"><xref derivedContent="11.1" format="counter" sectionFormat="of" target="section-11.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.11.2.2">
                <t indent="0" pn="section-toc.1-1.11.2.2.1"><xref derivedContent="11.2" format="counter" sectionFormat="of" target="section-11.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.13">
            <t indent="0" pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
        This document updates some OSPF terminology to be in line with inclusive language used in the industry.
        The IETF has designated "Guidance for NIST Staff on Using
        Inclusive Language in Documentary Standards" by the US National Institute of Standards and Technology (NIST) <xref target="NISTIR8366" format="default" sectionFormat="of" derivedContent="NISTIR8366"/> for its inclusive language guidelines.
        It is intended that all future OSPF documents use this revised terminology even when they reference the RFCs
        updated by this document.
      </t>
      <t indent="0" pn="section-1-2">
        This document updates <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>, <xref target="RFC4222" format="default" sectionFormat="of" derivedContent="RFC4222"/>,
        <xref target="RFC4811" format="default" sectionFormat="of" derivedContent="RFC4811"/>, <xref target="RFC5243" format="default" sectionFormat="of" derivedContent="RFC5243"/>, <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/>, <xref target="RFC5614" format="default" sectionFormat="of" derivedContent="RFC5614"/>,
        and <xref target="RFC5838" format="default" sectionFormat="of" derivedContent="RFC5838"/>.
      </t>
    </section>
    <section anchor="update" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-update-to-rfc-2328">Update to RFC 2328</name>
      <t indent="0" pn="section-2-1">
        The base OSPFv2 specification "OSPF Version 2" <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> defines the synchronization of
        databases as two routers forming a "master/slave" relationship.  All instances of these terms
        are replaced by "Leader/Follower", respectively.
      </t>
      <t indent="0" pn="section-2-2">
	In the Database Description packet, the "master (MS) bit" is renamed the "Leader (L) bit".
      </t>
      <t indent="0" pn="section-2-3">
        The operation of OSPFv2 is not modified. The Leader/Follower terminology and Leader (L) bit definition
        changes impact the following sections: "The Synchronization of Databases" (Section <xref target="RFC2328" section="7.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-7.2" derivedContent="RFC2328"/>), "The Neighbor Data Structure" (Section <xref target="RFC2328" section="10" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10" derivedContent="RFC2328"/>), "Neighbor states" (Section <xref target="RFC2328" section="10.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.1" derivedContent="RFC2328"/>), "Events causing neighbor state changes" (Section <xref target="RFC2328" section="10.2" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.2" derivedContent="RFC2328"/>), "The Neighbor state machine" (Section <xref target="RFC2328" section="10.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.3" derivedContent="RFC2328"/>), "Receiving Database Description Packets" (Section <xref target="RFC2328" section="10.6" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.6" derivedContent="RFC2328"/>), "Sending Database Description Packets" (Section <xref target="RFC2328" section="10.8" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.8" derivedContent="RFC2328"/>), "An Example" (Section <xref target="RFC2328" section="10.10" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#section-10.10" derivedContent="RFC2328"/>), and "The Database Description packet" (Appendix <xref target="RFC2328" section="A.3.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc2328#appendix-A.3.3" derivedContent="RFC2328"/>).
      </t>
    </section>
    <section anchor="update4222" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-update-to-rfc-4222">Update to RFC 4222</name>
      <t indent="0" pn="section-3-1">
        "Prioritized Treatment of Specific OSPF Version 2 Packets and
        Congestion Avoidance" <xref target="RFC4222" format="default" sectionFormat="of" derivedContent="RFC4222"/> is a Best Current Practice (BCP) document.  In Appendix <xref target="RFC4222" section="C" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4222#appendix-C" derivedContent="RFC4222"/>, Item (2), there is an example OSFPv2 packet sequence that refers to the "slave" in a database exchange; this reference is renamed to "Follower".
      </t>
    </section>
    <section anchor="update4811" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-update-to-rfc-4811">Update to RFC 4811</name>
      <t indent="0" pn="section-4-1">
        "OSPF Out-of-Band Link State Database (LSDB) Resynchronization" <xref target="RFC4811" format="default" sectionFormat="of" derivedContent="RFC4811"/> is an Informational document.
        Section <xref target="RFC4811" section="2.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4811#section-2.4" derivedContent="RFC4811"/> includes a Database Description packet (Figure 2) and a description of the attendant encoding
        changes for Out-of-Band Resynchronization. In the figure and the description, all instances of "MS" (when
        referring to the Database Description packet bit) are renamed to "L". There is also a reference to "Master" in
        this section that is renamed to "Leader".
      </t>
    </section>
    <section anchor="update5243" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-update-to-rfc-5243">Update to RFC 5243</name>
      <t indent="0" pn="section-5-1">
         "OSPF Database Exchange Summary List Optimization" <xref target="RFC5243" format="default" sectionFormat="of" derivedContent="RFC5243"/> is an Informational document.
        The Introduction (Section <xref target="RFC5243" section="1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5243#section-1" derivedContent="RFC5243"/>) references "Master or Slave"; this is replaced by "Leader or Follower".
        Section <xref target="RFC5243" section="3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5243#section-3" derivedContent="RFC5243"/> includes an example of the optimized database exchange. In this example, all instances of
        "Master" and "Slave" are renamed to "Leader" and "Follower", respectively.
      </t>
    </section>
    <section anchor="updatev6" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-update-to-rfc-5340">Update to RFC 5340</name>
      <t indent="0" pn="section-6-1">
        The base OSPFv3 specification "OSPF for IPv6" <xref target="RFC5340" format="default" sectionFormat="of" derivedContent="RFC5340"/> defines the Database Description process
        between two routers as one being "designated to be the master and the other is the slave".  All instances of these
        terms are replaced by "Leader/Follower", respectively.
      </t>
      <t indent="0" pn="section-6-2">
	In the Database Description packet, the "Master/Slave (MS) bit" is renamed the "Leader (L) bit".
      </t>
      <t indent="0" pn="section-6-3">
        The operation of OSPFv3 is not modified. The Leader/Follower terminology and Leader (L) bit definition
        changes impact "The Database Description Packet" (Appendix <xref target="RFC5340" section="A.3.3" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5340#appendix-A.3.3" derivedContent="RFC5340"/>).
      </t>
    </section>
    <section anchor="update5614" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-update-to-rfc-5614">Update to RFC 5614</name>
      <t indent="0" pn="section-7-1">
        "Mobile Ad Hoc Network (MANET) Extension of OSPF
        Using Connected Dominating Set (CDS) Flooding" <xref target="RFC5614" format="default" sectionFormat="of" derivedContent="RFC5614"/> is an Experimental document.
        "Changes to the Neighbor State Machine" (Section <xref target="RFC5614" section="7.1" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5614#section-7.1" derivedContent="RFC5614"/>) contains modifications to the neighbor
        state machine that were updated from <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/>. In the neighbor state machine modifications, all
        instances of "Master" and "Slave" are renamed to "Leader" and "Follower", respectively.
        Additionally, all instances of "MS" (when referring to the Database Description packet
        bit) are renamed to "L". And in "Receiving Database Description Packets" (Section <xref target="RFC5614" section="7.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5614#section-7.5" derivedContent="RFC5614"/>), "master or slave" is replaced by "Leader or Follower" in the parenthetical.
      </t>
    </section>
    <section anchor="update5838" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-update-to-rfc-5838">Update to RFC 5838</name>
      <t indent="0" pn="section-8-1">
         "Support of Address Families in OSPFv3" <xref target="RFC5838" format="default" sectionFormat="of" derivedContent="RFC5838"/> is a Standards Track document.
        "Database Description Maximum Transmission Unit (MTU)
        Specification for Non-IPv6 AFs" (Section <xref target="RFC5838" section="2.7" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5838#section-2.7" derivedContent="RFC5838"/>) contains a Database Description
        packet change figure that includes the MS bit. In this figure, the "MS" field is
        renamed the "L" field.
      </t>
      <t indent="0" pn="section-8-2">
        Additionally, in the first paragraph of "Changes to the Hello Packet Processing" (Section <xref target="RFC5838" section="2.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5838#section-2.4" derivedContent="RFC5838"/>),
        the text is updated to remove the non-inclusive terms pertaining to
        unreachability handling as follows:
      </t>
      <blockquote pn="section-8-3">
   When an OSPFv3 router does not support this specification and an
   interface is configured with the Instance ID corresponding to an
   IPv4 AF, packets could be routed toward this interface and
   dropped. This could happen due to misconfiguration or a router
   software downgrade. For example, an IPv4 packet
   could be received on an interface not supporting IPv4 since
   a router that doesn't support this specification can still
   include the interface in an SPF-calculated path as long as it
   establishes adjacencies using the Instance ID corresponding
   to the IPv4 AF. Note that OSPFv3 Router-LSAs and Network-LSAs are
   AF-agnostic.
 </blockquote>
    </section>
    <section anchor="IANA" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-9-1">In the "Database Description (DD) Packet Flags"
      registry, IANA has updated the description for value 0x01 to "Leader (L-bit)" and has added this document as a reference, as shown below.</t>
      <dl spacing="compact" indent="3" newline="false" pn="section-9-2">
        <dt pn="section-9-2.1">Value:</dt>
        <dd pn="section-9-2.2">0x01</dd>
        <dt pn="section-9-2.3">Description:</dt>
        <dd pn="section-9-2.4">Leader (L-bit)</dd>
        <dt pn="section-9-2.5">Reference:</dt>
        <dd pn="section-9-2.6">
          <xref target="RFC2328" format="default" sectionFormat="of" derivedContent="RFC2328"/> [RFC9454]</dd>
      </dl>
    </section>
    <section anchor="Security" numbered="true" toc="include" removeInRFC="false" pn="section-10">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-10-1">
        This document updates the terminology used in OSPF RFCs without any modification to the specifications of the protocol.
        As such, the security characteristics of OSPF do not change.
      </t>
    </section>
  </middle>
  <back>
    <references pn="section-11">
      <name slugifiedName="name-references">References</name>
      <references pn="section-11.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2328" target="https://www.rfc-editor.org/info/rfc2328" quoteTitle="true" derivedAnchor="RFC2328">
          <front>
            <title>OSPF Version 2</title>
            <author fullname="J. Moy" initials="J." surname="Moy"/>
            <date month="April" year="1998"/>
            <abstract>
              <t indent="0">This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="54"/>
          <seriesInfo name="RFC" value="2328"/>
          <seriesInfo name="DOI" value="10.17487/RFC2328"/>
        </reference>
        <reference anchor="RFC4222" target="https://www.rfc-editor.org/info/rfc4222" quoteTitle="true" derivedAnchor="RFC4222">
          <front>
            <title>Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance</title>
            <author fullname="G. Choudhury" initials="G." role="editor" surname="Choudhury"/>
            <date month="October" year="2005"/>
            <abstract>
              <t indent="0">This document recommends methods that are intended to improve the scalability and stability of large networks using Open Shortest Path First (OSPF) Version 2 protocol. The methods include processing OSPF Hellos and Link State Advertisement (LSA) Acknowledgments at a higher priority compared to other OSPF packets, and other congestion avoidance procedures. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="112"/>
          <seriesInfo name="RFC" value="4222"/>
          <seriesInfo name="DOI" value="10.17487/RFC4222"/>
        </reference>
        <reference anchor="RFC4811" target="https://www.rfc-editor.org/info/rfc4811" quoteTitle="true" derivedAnchor="RFC4811">
          <front>
            <title>OSPF Out-of-Band Link State Database (LSDB) Resynchronization</title>
            <author fullname="L. Nguyen" initials="L." surname="Nguyen"/>
            <author fullname="A. Roy" initials="A." surname="Roy"/>
            <author fullname="A. Zinin" initials="A." surname="Zinin"/>
            <date month="March" year="2007"/>
            <abstract>
              <t indent="0">OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network.</t>
              <t indent="0">This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4811"/>
          <seriesInfo name="DOI" value="10.17487/RFC4811"/>
        </reference>
        <reference anchor="RFC5243" target="https://www.rfc-editor.org/info/rfc5243" quoteTitle="true" derivedAnchor="RFC5243">
          <front>
            <title>OSPF Database Exchange Summary List Optimization</title>
            <author fullname="R. Ogier" initials="R." surname="Ogier"/>
            <date month="May" year="2008"/>
            <abstract>
              <t indent="0">This document describes a backward-compatible optimization for the Database Exchange process in OSPFv2 and OSPFv3. In this optimization, a router does not list a Link State Advertisement (LSA) in Database Description packets sent to a neighbor, if the same or a more recent instance of the LSA was listed in a Database Description packet already received from the neighbor. This optimization reduces Database Description overhead by about 50% in large networks. This optimization does not affect synchronization, since it only omits unnecessary information from Database Description packets. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5243"/>
          <seriesInfo name="DOI" value="10.17487/RFC5243"/>
        </reference>
        <reference anchor="RFC5340" target="https://www.rfc-editor.org/info/rfc5340" quoteTitle="true" derivedAnchor="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"/>
            <date month="July" year="2008"/>
            <abstract>
              <t indent="0">This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).</t>
              <t indent="0">Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).</t>
              <t indent="0">Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.</t>
              <t indent="0">All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5340"/>
          <seriesInfo name="DOI" value="10.17487/RFC5340"/>
        </reference>
        <reference anchor="RFC5614" target="https://www.rfc-editor.org/info/rfc5614" quoteTitle="true" derivedAnchor="RFC5614">
          <front>
            <title>Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding</title>
            <author fullname="R. Ogier" initials="R." surname="Ogier"/>
            <author fullname="P. Spagnolo" initials="P." surname="Spagnolo"/>
            <date month="August" year="2009"/>
            <abstract>
              <t indent="0">This document specifies an extension of OSPFv3 to support mobile ad hoc networks (MANETs). The extension, called OSPF-MDR, is designed as a new OSPF interface type for MANETs. OSPF-MDR is based on the selection of a subset of MANET routers, consisting of MANET Designated Routers (MDRs) and Backup MDRs. The MDRs form a connected dominating set (CDS), and the MDRs and Backup MDRs together form a biconnected CDS for robustness. This CDS is exploited in two ways. First, to reduce flooding overhead, an optimized flooding procedure is used in which only (Backup) MDRs flood new link state advertisements (LSAs) back out the receiving interface; reliable flooding is ensured by retransmitting LSAs along adjacencies. Second, adjacencies are formed only between (Backup) MDRs and a subset of their neighbors, allowing for much better scaling in dense networks. The CDS is constructed using 2-hop neighbor information provided in a Hello protocol extension. The Hello protocol is further optimized by allowing differential Hellos that report only changes in neighbor states. Options are specified for originating router-LSAs that provide full or partial topology information, allowing overhead to be reduced by advertising less topology information. This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5614"/>
          <seriesInfo name="DOI" value="10.17487/RFC5614"/>
        </reference>
        <reference anchor="RFC5838" target="https://www.rfc-editor.org/info/rfc5838" quoteTitle="true" derivedAnchor="RFC5838">
          <front>
            <title>Support of Address Families in OSPFv3</title>
            <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/>
            <author fullname="S. Mirtorabi" initials="S." surname="Mirtorabi"/>
            <author fullname="A. Roy" initials="A." surname="Roy"/>
            <author fullname="M. Barnes" initials="M." surname="Barnes"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <date month="April" year="2010"/>
            <abstract>
              <t indent="0">This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5838"/>
          <seriesInfo name="DOI" value="10.17487/RFC5838"/>
        </reference>
      </references>
      <references pn="section-11.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="NISTIR8366" target="https://doi.org/10.6028/NIST.IR.8366" quoteTitle="true" derivedAnchor="NISTIR8366">
          <front>
            <title>Guidance for NIST Staff on Using Inclusive Language in Documentary Standards</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology (NIST)</organization>
            </author>
            <date year="2021" month="April"/>
          </front>
          <seriesInfo name="NIST Interagency/Internal Report (NISTIR)" value="8366"/>
        </reference>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">Thanks to <contact fullname="Dhruv Dhody"/>,  <contact fullname="Adrian Farrel"/>, <contact fullname="Erik Kline"/>, and <contact fullname="Barry Leiba"/> for their reviews and comments.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M" surname="Fox" fullname="Mike Fox">
        <organization showOnFrontPage="true">IBM</organization>
        <address>
          <postal>
            <street>3039 E Cornwallis Rd.</street>
            <city>Research Triangle Park</city>
            <region>NC</region>
            <code>27709</code>
            <country>United States of America</country>
          </postal>
          <email>mjfox@us.ibm.com</email>
        </address>
      </author>
      <author initials="A" surname="Lindem" fullname="Acee Lindem">
        <organization showOnFrontPage="true">LabN Consulting, L.L.C.</organization>
        <address>
          <postal>
            <street>301 Midenhall Way</street>
            <city>Cary</city>
            <region>NC</region>
            <code>27513</code>
            <country>United States of America</country>
          </postal>
          <email>acee.ietf@gmail.com</email>
        </address>
      </author>
      <author initials="A" surname="Retana" fullname="Alvaro Retana">
        <organization showOnFrontPage="true">Futurewei Technologies, Inc.</organization>
        <address>
          <postal>
            <street>2330 Central Expressway</street>
            <city>Santa Clara</city>
            <region>CA</region>
            <code>95050</code>
            <country>United States of America</country>
          </postal>
          <email>aretana@futurewei.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
