rfc9454.original   rfc9454.txt 
Link State Routing M. Fox Internet Engineering Task Force (IETF) M. Fox
Internet-Draft IBM Request for Comments: 9454 IBM
Updates: 2328 5340 4222 4811 5243 5614 5838 (if A. Lindem Updates: 2328 4222 4811 5243 5340 5614 5838 A. Lindem
approved) LabN Consulting LLC Category: Standards Track LabN Consulting, L.L.C.
Intended status: Standards Track A. Retana ISSN: 2070-1721 A. Retana
Expires: 26 November 2023 Futurewei Technologies, Inc. Futurewei Technologies, Inc.
25 May 2023 August 2023
Update to OSPF Terminology Update to OSPF Terminology
draft-ietf-lsr-ospf-terminology-09
Abstract Abstract
This document updates some OSPF terminology to be in line with This document updates some OSPF terminology to be in line with
inclusive language used in the industry. The IETF has designated US inclusive language used in the industry. The IETF has designated
National Institute of Standards and Technology (NIST) "Guidance for "Guidance for NIST Staff on Using Inclusive Language in Documentary
NIST Staff on Using Inclusive Language in Documentary Standards" for Standards" by the US National Institute of Standards and Technology
its inclusive language guidelines. It is intended that all future (NIST) for its inclusive language guidelines. It is intended that
OSPF documents use this revised terminology even when they reference all future OSPF documents use this revised terminology even when they
the RFCs updated by this document. reference the RFCs updated by this document.
This document updates RFC2328, RFC5340, RFC4222, RFC4811, RFC5243, This document updates RFCs 2328, 4222, 4811, 5243, 5340, 5614, and
RFC5614, and RFC5838. 5838.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 26 November 2023. 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 Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Update to RFC2328 . . . . . . . . . . . . . . . . . . . . . . 2 2. Update to RFC 2328
3. Update to RFC5340 . . . . . . . . . . . . . . . . . . . . . . 3 3. Update to RFC 4222
4. Update to RFC4222 . . . . . . . . . . . . . . . . . . . . . . 3 4. Update to RFC 4811
5. Update to RFC4811 . . . . . . . . . . . . . . . . . . . . . . 3 5. Update to RFC 5243
6. Update to RFC5243 . . . . . . . . . . . . . . . . . . . . . . 4 6. Update to RFC 5340
7. Update to RFC5614 . . . . . . . . . . . . . . . . . . . . . . 4 7. Update to RFC 5614
8. Update to RFC5838 . . . . . . . . . . . . . . . . . . . . . . 4 8. Update to RFC 5838
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 10. Security Considerations
11. Security Considerations . . . . . . . . . . . . . . . . . . . 5 11. References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 11.1. Normative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 5 11.2. Informative References
12.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses
1. Introduction 1. Introduction
This document updates some OSPF terminology to be in line with This document updates some OSPF terminology to be in line with
inclusive language used in the industry. The IETF has designated US inclusive language used in the industry. The IETF has designated
National Institute of Standards and Technology (NIST) "Guidance for "Guidance for NIST Staff on Using Inclusive Language in Documentary
NIST Staff on Using Inclusive Language in Documentary Standards" Standards" by the US National Institute of Standards and Technology
[NISTIR8366] for its inclusive language guidelines. It is intended (NIST) [NISTIR8366] for its inclusive language guidelines. It is
that all future OSPF documents use this revised terminology even when intended that all future OSPF documents use this revised terminology
they reference the RFCs updated by this document. even when they reference the RFCs updated by this document.
This document updates [RFC2328], [RFC5340], [RFC4222], [RFC4811], This document updates [RFC2328], [RFC4222], [RFC4811], [RFC5243],
[RFC5243], [RFC5614], and [RFC5838]. [RFC5340], [RFC5614], and [RFC5838].
2. Update to RFC2328 2. Update to RFC 2328
The base OSPFv2 specification [RFC2328] defines the synchronization The base OSPFv2 specification "OSPF Version 2" [RFC2328] defines the
of databases as two routers forming a "master/slave relationship". synchronization of databases as two routers forming a "master/slave"
All instances of these terms are replaced by Leader/Follower, relationship. All instances of these terms are replaced by "Leader/
respectively. Follower", respectively.
The Master (MS) bit in the database description packet is renamed the In the Database Description packet, the "master (MS) bit" is renamed
Leader (L) bit. the "Leader (L) bit".
The operation of OSPFv2 is not modified. The Leader/Follower The operation of OSPFv2 is not modified. The Leader/Follower
terminology and Leader (L) Bit definition changes impact the terminology and Leader (L) bit definition changes impact the
following sections: 7.2 "The Synchronization of Databases", 10 "The following sections: "The Synchronization of Databases" (Section 7.2),
Neighbor Data Structures", 10.1 "Neighbor states", 10.2 "Events "The Neighbor Data Structure" (Section 10), "Neighbor states"
causing neighbor state changes", 10.3 "The Neighbor state machine", (Section 10.1), "Events causing neighbor state changes"
10.6 "Receiving Database Description Packets", 10.8 "Sending Database (Section 10.2), "The Neighbor state machine" (Section 10.3),
Description Packets", 10.10 "An Example", and A.3.3 "The Database "Receiving Database Description Packets" (Section 10.6), "Sending
Description packet". Database Description Packets" (Section 10.8), "An Example"
(Section 10.10), and "The Database Description packet"
3. Update to RFC5340 (Appendix A.3.3).
The base OSPFv3 specification [RFC5340] defines the database 3. Update to RFC 4222
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.
The Master/Slave (MS) bit in the database description packet is "Prioritized Treatment of Specific OSPF Version 2 Packets and
renamed the Leader (L) bit. 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".
The operation of OSPFv3 is not modified. The Leader/Follower 4. Update to RFC 4811
terminology and Leader (L) Bit definition changes impact section
A.3.3 "The Database Description packet".
4. Update to RFC4222 "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".
This Best Current Practice (BCP) document describes "Prioritized 5. Update to RFC 5243
Treatment of Specific OSPF Version 2 Packets and Congestion
Avoidance" [RFC4222]. There is an example OSFPv2 packet sequence in
Appendix C, (2), that refers to the "slave" in a database exchange.
This reference will be renamed to "Follower".
5. Update to RFC4811 "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.
This Experimental document specifies "OSPF Out-of-Band Link State 6. Update to RFC 5340
Database (LSDB) Resynchronization" [RFC4811]. 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".
6. Update to RFC5243 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.
This Informational document describes an "OSPF Database Exchange In the Database Description packet, the "Master/Slave (MS) bit" is
Summary List Optimization" [RFC5243]. The Introduction, Section 1, renamed the "Leader (L) bit".
references "Master or Slave". This will be replaced by "Leader or
Follower". Section 3.0 includes an example of the optimized database
exchange. In this example, all instances of "Master" will be renamed
to "Leader" and all instances of "Slave" will be renamed to
"Follower".
7. Update to RFC5614 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).
This Experimental document specifies the "Mobile Ad Hoc Network 7. Update to RFC 5614
(MANET) Extension of OSPF Using Connected Dominating Set (CDS)
Flooding" [RFC5614]. "Changes to the Neighbor State Machine",
Section 7.2 contains modifications to the neighbor state machine
updated from [RFC2328]. In this transition to "2-way" state, all
instances of "Master" are renamed to "Leader" and all instances of
"Slave" are renamed to "Follower". Additionally, instances of "MS"
in reference to the Database Description packet bit are renamed to
"L". Additionally, in "Receiving Database Description Packets,
Section 7.5, the parenthentical "master or slave" is replaced by
"Leader or Follower".
8. Update to RFC5838 "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.
This Standards Track document specifies the "Support of Address 8. Update to RFC 5838
Families in OSPFv3" [RFC5838]. "Database Description Maximum
Transmission Unit (MTU) Specification for Non-IPv6 AFs", Section 2.7
contains a Database Description packet change figure which include
the "MS" bit. In this figure, the "MS" field will be renamed to "L"
field.
Additionally, in Section 2.4.,first paragraph, "Changes to the Hello "Support of Address Families in OSPFv3" [RFC5838] is a Standards
Packet Processing", the text is updated to remove the non-inclusive Track document. "Database Description Maximum Transmission Unit
terms pertaining to unreachability handling as follows: (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.
When an OSPFv3 router does not support this specification and an Additionally, in the first paragraph of "Changes to the Hello Packet
interface is configured with the Instance ID corresponding to a Processing" (Section 2.4), the text is updated to remove the non-
IPv4 AF, packets could be routed toward this interface and inclusive terms pertaining to unreachability handling as follows:
dropped. This could happen due to misconfiguration or a router
software downgrade. Packet reception and dropping on an interface
not configured with the packet AF. 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 OSPPFv3 Router-LSAs and Network-LSAs are
AF-agnostic.
9. Acknowledgements | 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.
Thanks to Dhruv Dhody, Adrian Farrel, Barry Leiba, and Erik Kline for 9. IANA Considerations
review and comments.
10. 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.
IANA is requested to rename bit 0x01 in the "Database Description Value: 0x01
(DD) Packet Flags" registry to "Leader (L-bit)" and to add a Description: Leader (L-bit)
reference to this document. Reference: [RFC2328] [RFC9454]
11. Security Considerations 10. Security Considerations
This document updates the terminology used in OSPF RFCs without any This document updates the terminology used in OSPF RFCs without any
modification to the specifications of the protocol. As such, the modification to the specifications of the protocol. As such, the
security characteristics of OSPF do not change. security characteristics of OSPF do not change.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
[RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific [RFC4222] Choudhury, G., Ed., "Prioritized Treatment of Specific
OSPF Version 2 Packets and Congestion Avoidance", BCP 112, OSPF Version 2 Packets and Congestion Avoidance", BCP 112,
RFC 4222, DOI 10.17487/RFC4222, October 2005, RFC 4222, DOI 10.17487/RFC4222, October 2005,
<https://www.rfc-editor.org/info/rfc4222>. <https://www.rfc-editor.org/info/rfc4222>.
skipping to change at page 6, line 23 skipping to change at line 238
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
Extension of OSPF Using Connected Dominating Set (CDS) Extension of OSPF Using Connected Dominating Set (CDS)
Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009, Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009,
<https://www.rfc-editor.org/info/rfc5614>. <https://www.rfc-editor.org/info/rfc5614>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
R. Aggarwal, "Support of Address Families in OSPFv3", R. Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, DOI 10.17487/RFC5838, April 2010, RFC 5838, DOI 10.17487/RFC5838, April 2010,
<https://www.rfc-editor.org/info/rfc5838>. <https://www.rfc-editor.org/info/rfc5838>.
12.2. Informative References 11.2. Informative References
[NISTIR8366] [NISTIR8366]
National Institute of Standards and Technology (NIST),
"Guidance for NIST Staff on Using Inclusive Language in "Guidance for NIST Staff on Using Inclusive Language in
Documentary Standards, National Institute of Standards and Documentary Standards", NIST Interagency/Internal Report
Technology (NIST) Interagency or Internal Report 8366", (NISTIR) 8366, April 2021,
NISTIR 8366, April 2021,
<https://doi.org/10.6028/NIST.IR.8366>. <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 Authors' Addresses
Mike Fox Mike Fox
IBM IBM
3039 E Cornwallis Rd 3039 E Cornwallis Rd.
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
United States of America United States of America
Email: mjfox@us.ibm.com Email: mjfox@us.ibm.com
Acee Lindem Acee Lindem
LabN Consulting LLC LabN Consulting, L.L.C.
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
United States of America United States of America
Email: acee.ietf@gmail.com Email: acee.ietf@gmail.com
Alvaro Retana Alvaro Retana
Futurewei Technologies, Inc. Futurewei Technologies, Inc.
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
United States of America United States of America
Email: aretana@futurewei.com Email: aretana@futurewei.com
 End of changes. 44 change blocks. 
155 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.48.