diff options
Diffstat (limited to 'doc/rfc/rfc9454.txt')
| -rw-r--r-- | doc/rfc/rfc9454.txt | 279 |
1 files changed, 279 insertions, 0 deletions
diff --git a/doc/rfc/rfc9454.txt b/doc/rfc/rfc9454.txt new file mode 100644 index 0000000..5c83fd2 --- /dev/null +++ b/doc/rfc/rfc9454.txt @@ -0,0 +1,279 @@ + + + + +Internet Engineering Task Force (IETF) M. Fox +Request for Comments: 9454 IBM +Updates: 2328, 4222, 4811, 5243, 5340, 5614, A. Lindem + 5838 LabN Consulting, L.L.C. +Category: Standards Track A. Retana +ISSN: 2070-1721 Futurewei Technologies, Inc. + August 2023 + + + Update to OSPF Terminology + +Abstract + + 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 + https://www.rfc-editor.org/info/rfc9454. + +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 + (https://trustee.ietf.org/license-info) 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 + + 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 + + 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) [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. + + This document updates [RFC2328], [RFC4222], [RFC4811], [RFC5243], + [RFC5340], [RFC5614], and [RFC5838]. + +2. Update to RFC 2328 + + The base OSPFv2 specification "OSPF Version 2" [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. + + 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 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) + document. In Appendix C, Item (2), there is an example OSFPv2 packet + sequence that refers to the "slave" in a database exchange; this + reference is renamed to "Follower". + +4. Update to RFC 4811 + + "OSPF Out-of-Band Link State Database (LSDB) Resynchronization" + [RFC4811] is an Informational document. Section 2.4 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". + +5. Update to RFC 5243 + + "OSPF Database Exchange Summary List Optimization" [RFC5243] is an + Informational document. The Introduction (Section 1) references + "Master or Slave"; this is replaced by "Leader or Follower". + Section 3 includes an example of the optimized database exchange. In + this example, all instances of "Master" and "Slave" are renamed to + "Leader" and "Follower", respectively. + +6. Update to RFC 5340 + + The base OSPFv3 specification "OSPF for IPv6" [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. + + 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 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 document. + "Changes to the Neighbor State Machine" (Section 7.1) contains + modifications to the neighbor state machine that were updated from + [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 7.5), + "master or slave" is replaced by "Leader or Follower" in the + parenthetical. + +8. Update to RFC 5838 + + "Support of Address Families in OSPFv3" [RFC5838] is a Standards + Track document. "Database Description Maximum Transmission Unit + (MTU) Specification for Non-IPv6 AFs" (Section 2.7) 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 2.4), 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. + +9. 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: [RFC2328] [RFC9454] + +10. 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. + +11. References + +11.1. Normative References + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + DOI 10.17487/RFC2328, April 1998, + <https://www.rfc-editor.org/info/rfc2328>. + + [RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific + OSPF Version 2 Packets and Congestion Avoidance", BCP 112, + RFC 4222, DOI 10.17487/RFC4222, October 2005, + <https://www.rfc-editor.org/info/rfc4222>. + + [RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link + State Database (LSDB) Resynchronization", RFC 4811, + DOI 10.17487/RFC4811, March 2007, + <https://www.rfc-editor.org/info/rfc4811>. + + [RFC5243] Ogier, R., "OSPF Database Exchange Summary List + Optimization", RFC 5243, DOI 10.17487/RFC5243, May 2008, + <https://www.rfc-editor.org/info/rfc5243>. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, + <https://www.rfc-editor.org/info/rfc5340>. + + [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) + Extension of OSPF Using Connected Dominating Set (CDS) + Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, + <https://www.rfc-editor.org/info/rfc5614>. + + [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and + R. Aggarwal, "Support of Address Families in OSPFv3", + RFC 5838, DOI 10.17487/RFC5838, April 2010, + <https://www.rfc-editor.org/info/rfc5838>. + +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 + + 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 |