RFC 9454

Update to OSPF Terminology

📅 published August 2023, from ietf

RFC 9454: Update to OSPF Terminology 💖

okay bestie, this one's a glow-up doc! ✨ It's RFC 9454, a Standards Track document from August 2023 (ISSN 2070-1721) written by Mike Fox (IBM), Acee Lindem (LabN Consulting, L.L.C.), and Alvaro Retana (Futurewei Technologies, Inc.). It updates RFC 2328, 4222, 4811, 5243, 5340, 5614, and 5838 🦋. The whole point is swapping out OSPF's old "master/slave" language for more inclusive terms 🌈.

Abstract

This doc updates some OSPF terminology so it matches the inclusive language used across the industry 💅. The IETF picked "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" from the US National Institute of Standards and Technology (NIST) as its inclusive language guide. All future OSPF docs are supposed to use this new vocab, even when they point back at the RFCs updated here 🫶.

This doc updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and 5838.

Status of This Memo

This is an Internet Standards Track doc 🔥. It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. For more on Internet Standards, check Section 2 of RFC 7841 📚.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9454 ✨.

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Please actually read these, because they spell out your rights and restrictions for this doc 🙈. Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 🫶.

Table of Contents

  • 1. Introduction
  • 2. Update to RFC 2328
  • 3. Update to RFC 4222
  • 4. Update to RFC 4811
  • 5. Update to RFC 5243
  • 6. Update to RFC 5340
  • 7. Update to RFC 5614
  • 8. Update to RFC 5838
  • 9. IANA Considerations
  • 10. Security Considerations
  • 11. References
    • 11.1. Normative References
    • 11.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction ✨

Okay so the intro says the same thing as the abstract 🌸. This doc updates some OSPF terminology to match the inclusive language used in the industry. The IETF designated "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards" from the US National Institute of Standards and Technology (NIST) [NISTIR8366] as its inclusive language guidelines. All future OSPF docs should use this revised terminology even when they reference the RFCs updated by this doc 💅.

This doc updates [RFC2328], [RFC4222], [RFC4811], [RFC5243], [RFC5340], [RFC5614], and [RFC5838] 🦋.

2. Update to RFC 2328 🎀

The base OSPFv2 spec, "OSPF Version 2" [RFC2328], describes database synchronization as two routers forming a "master/slave" relationship. Every instance of those terms gets replaced with "Leader/Follower", respectively 🍓.

In the Database Description packet, the "master (MS) bit" is renamed to the "Leader (L) bit" 👑.

OSPFv2 itself isn't changing. The Leader/Follower terminology and the Leader (L) bit definition do affect these sections: "The Synchronization of Databases" (Section 7.2), "The Neighbor Data Structure" (Section 10), "Neighbor states" (Section 10.1), "Events causing neighbor state changes" (Section 10.2), "The Neighbor state machine" (Section 10.3), "Receiving Database Description Packets" (Section 10.6), "Sending Database Description Packets" (Section 10.8), "An Example" (Section 10.10), and "The Database Description packet" (Appendix A.3.3) 📚.

3. Update to RFC 4222 🌈

"Prioritized Treatment of Specific OSPF Version 2 Packets and Congestion Avoidance" [RFC4222] is a Best Current Practice (BCP) doc 🧚. In Appendix C, Item (2), there's an example OSFPv2 packet sequence that mentions the "slave" in a database exchange. That reference gets renamed to "Follower" 💜.

4. Update to RFC 4811 🦋

"OSPF Out-of-Band Link State Database (LSDB) Resynchronization" [RFC4811] is an Informational doc 🌸. Section 2.4 has a Database Description packet (Figure 2) plus a description of the encoding changes for Out-of-Band Resynchronization. In the figure and the description, every "MS" (when it refers to the Database Description packet bit) becomes "L" ✨. There's also a "Master" reference in this section, and that one becomes "Leader" 👑.

5. Update to RFC 5243 💅

"OSPF Database Exchange Summary List Optimization" [RFC5243] is an Informational doc 🎀. The Introduction (Section 1) mentions "Master or Slave", and that gets replaced by "Leader or Follower" 🫶. Section 3 has an example of the optimized database exchange, and in it, every "Master" becomes "Leader" and every "Slave" becomes "Follower" 🍓.

6. Update to RFC 5340 💖

The base OSPFv3 spec, "OSPF for IPv6" [RFC5340], describes the Database Description process between two routers as one being "designated to be the master and the other is the slave". Every instance of those terms becomes "Leader/Follower", respectively 🌈.

In the Database Description packet, the "Master/Slave (MS) bit" gets renamed to the "Leader (L) bit" 👑.

OSPFv3 itself isn't changing. The Leader/Follower terminology and Leader (L) bit definition do affect "The Database Description Packet" (Appendix A.3.3) 📚.

7. Update to RFC 5614 🧚

"Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding" [RFC5614] is an Experimental doc ✨. "Changes to the Neighbor State Machine" (Section 7.1) has modifications to the neighbor state machine that were carried over from [RFC2328] 🦋. In those modifications, every "Master" becomes "Leader" and every "Slave" becomes "Follower" 💜. Also, every "MS" (when it refers to the Database Description packet bit) becomes "L" 🌸. And in "Receiving Database Description Packets" (Section 7.5), "master or slave" becomes "Leader or Follower" in the parenthetical 🫶.

8. Update to RFC 5838 🎀

"Support of Address Families in OSPFv3" [RFC5838] is a Standards Track doc 🔥. "Database Description Maximum Transmission Unit (MTU) Specification for Non-IPv6 AFs" (Section 2.7) has a Database Description packet change figure that includes the MS bit. In that figure, the "MS" field becomes the "L" field 👑.

Also, the first paragraph of "Changes to the Hello Packet Processing" (Section 2.4) gets updated to drop the non-inclusive terms about unreachability handling. It now reads:

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.

9. IANA Considerations 🌈

In the "Database Description (DD) Packet Flags" registry, IANA updated the description for value 0x01 to "Leader (L-bit)" and added this doc as a reference, as shown below 💅.

Value:  0x01
Description:  Leader (L-bit)
Reference:  [RFC2328] [RFC9454]

10. Security Considerations 💀

Okay, this section is short but it's iconic 😭. This doc only updates the terminology used in the OSPF RFCs. It doesn't change the protocol specifications at all 🫶. So the security characteristics of OSPF stay exactly the same 🔒. Nothing new to panic about, bestie 💜.

11. References 📚

11.1. Normative References

11.2. Informative References

  • [NISTIR8366]: National Institute of Standards and Technology (NIST), "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards", NIST Interagency/Internal Report (NISTIR) 8366, April 2021, <https://doi.org/10.6028/NIST.IR.8366>.

Acknowledgements 🫶

Huge thanks to Dhruv Dhody, Adrian Farrel, Erik Kline, and Barry Leiba for their reviews and comments 💖.

Authors' Addresses 🧚

Mike Fox
IBM
3039 E Cornwallis Rd.
Research Triangle Park, NC 27709
United States of America
Email: mjfox@us.ibm.com

Acee Lindem
LabN Consulting, L.L.C.
301 Midenhall Way
Cary, NC 27513
United States of America
Email: acee.ietf@gmail.com

Alvaro Retana
Futurewei Technologies, Inc.
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: aretana@futurewei.com

that's the whole doc, bestie!! 🌈💅✨

📦 where this page comes from