Update to OSPF Terminology IBM
3039 E Cornwallis Rd. Research Triangle Park NC 27709 United States of America mjfox@us.ibm.com
LabN Consulting, L.L.C.
301 Midenhall Way Cary NC 27513 United States of America acee.ietf@gmail.com
Futurewei Technologies, Inc.
2330 Central Expressway Santa Clara CA 95050 United States of America aretana@futurewei.com
rtg lsr OSPF terminology 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. This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and 5838.
Status of This Memo This is an Internet Standards Track document. 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. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () 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.
Table of Contents
  • .  Introduction
  • .  Update to RFC 2328
  • .  Update to RFC 4222
  • .  Update to RFC 4811
  • .  Update to RFC 5243
  • .  Update to RFC 5340
  • .  Update to RFC 5614
  • .  Update to RFC 5838
  • .  IANA Considerations
  • . Security Considerations
  • . References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
Introduction 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. This document updates , , , , , , and .
Update to RFC 2328 The base OSPFv2 specification "OSPF Version 2" defines the synchronization of databases as two routers forming a "master/slave" relationship. All instances of these terms are replaced by "Leader/Follower", respectively. In the Database Description packet, the "master (MS) bit" is renamed the "Leader (L) bit". 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 ), "The Neighbor Data Structure" (Section ), "Neighbor states" (Section ), "Events causing neighbor state changes" (Section ), "The Neighbor state machine" (Section ), "Receiving Database Description Packets" (Section ), "Sending Database Description Packets" (Section ), "An Example" (Section ), and "The Database Description packet" (Appendix ).
Update to RFC 4222 "Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance" is a Best Current Practice (BCP) document. In Appendix , Item (2), there is an example OSFPv2 packet sequence that refers to the "slave" in a database exchange; this reference is renamed to "Follower".
Update to RFC 4811 "OSPF Out-of-Band Link State Database (LSDB) Resynchronization" is an Informational document. Section 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".
Update to RFC 5243 "OSPF Database Exchange Summary List Optimization" is an Informational document. The Introduction (Section ) references "Master or Slave"; this is replaced by "Leader or Follower". Section includes an example of the optimized database exchange. In this example, all instances of "Master" and "Slave" are renamed to "Leader" and "Follower", respectively.
Update to RFC 5340 The base OSPFv3 specification "OSPF for IPv6" 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. In the Database Description packet, the "Master/Slave (MS) bit" is renamed the "Leader (L) bit". The operation of OSPFv3 is not modified. The Leader/Follower terminology and Leader (L) bit definition changes impact "The Database Description Packet" (Appendix ).
Update to RFC 5614 "Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding" is an Experimental document. "Changes to the Neighbor State Machine" (Section ) contains modifications to the neighbor state machine that were updated from . 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 ), "master or slave" is replaced by "Leader or Follower" in the parenthetical.
Update to RFC 5838 "Support of Address Families in OSPFv3" is a Standards Track document. "Database Description Maximum Transmission Unit (MTU) Specification for Non-IPv6 AFs" (Section ) contains a Database Description packet change figure that includes the MS bit. In this figure, the "MS" field is renamed the "L" field. Additionally, in the first paragraph of "Changes to the Hello Packet Processing" (Section ), the text is updated to remove the non-inclusive terms pertaining to unreachability handling as follows:
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.
IANA Considerations 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.
Value:
0x01
Description:
Leader (L-bit)
Reference:
[RFC9454]
Security Considerations 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.
References Normative References OSPF Version 2 This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. [STANDARDS-TRACK] Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance 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. OSPF Out-of-Band Link State Database (LSDB) Resynchronization 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. 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. OSPF Database Exchange Summary List Optimization 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. OSPF for IPv6 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). 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). 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. 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] Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding 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. Support of Address Families in OSPFv3 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] Informative References Guidance for NIST Staff on Using Inclusive Language in Documentary Standards National Institute of Standards and Technology (NIST)
Acknowledgements Thanks to , , , and for their reviews and comments.
Authors' Addresses IBM
3039 E Cornwallis Rd. Research Triangle Park NC 27709 United States of America mjfox@us.ibm.com
LabN Consulting, L.L.C.
301 Midenhall Way Cary NC 27513 United States of America acee.ietf@gmail.com
Futurewei Technologies, Inc.
2330 Central Expressway Santa Clara CA 95050 United States of America aretana@futurewei.com