RFC 4136

RFC 4136: OSPF Refresh and Flooding Reduction in Stable Topologies 🎀

okay bestie, here's the title block tea ☕

• Series: Network Working Group
• Number: RFC 4136
• Author: Padma Pillay-Esnault, Cisco Systems 💖
• Category: Informational (it's info, not a standard 🙈)
• Date: July 2005
• Obsoletes / Updates: none listed, so this one doesn't obsolete or update any other RFC ✨

Status of This Memo 📜

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice ©️

Copyright (C) The Internet Society (2005).

Abstract 🌸

This doc describes an extension to OSPF that cuts down on the periodic flooding of Link State Advertisements (LSAs) when the topology is stable.

Right now, OSPF says that every LSA except DoNotAge LSAs has to be refreshed every 30 minutes. This doc proposes expanding the use of DoNotAge LSAs so there's way less protocol traffic in stable topologies 🦋

1. Introduction ✨

The explosion of IP-based networks has made everyone care about how well Interior Gateway Protocols like OSPF scale. OSPF networks are growing every day and will keep expanding to meet the demand for connections to the Internet or to intranets 🌈

ISPs and folks with big networks have noticed some non-negligible protocol traffic, even when their topologies are stable 👀

OSPF says every LSA must be refreshed every 1800 seconds, or else it expires when it hits 3600 seconds [1].

This doc tackles LSA expiration by generalizing the use of DoNotAge LSAs. That makes OSPF easier to scale, because it cuts the traffic overhead in stable topologies 💅

2. Changes in the Existing Implementation 🛠️

This enhancement depends on the DoNotAge bit and the Indication-LSA. The details of both are specified in "Extending OSPF to Support Demand Circuits" [2].

Flooding-reduction-capable routers keep sending hellos to their neighbors and keep aging their self-originated LSAs in their database. The difference is they flood their self-originated LSAs with the DoNotAge bit set. So self-originated LSAs don't have to be re-flooded every 30 minutes, and the re-flooding interval can stretch out to the configured forced-flooding interval 🫶

Like normal OSPF, any change in an LSA's contents causes a reoriginated LSA to be flooded with the DoNotAge bit set. Traffic overhead goes down, and changes still get flooded immediately. Iconic 🔥

Flooding-reduction-capable routers flood received non-self-originated LSAs with the DoNotAge bit set on all normal or flooding-reduction-only interfaces within the LSA's flooding scope. If an interface is configured as both flooding-reduction-capable and Demand-Circuit, flooding happens if and only if the LSA's contents have changed. That way the originating router can still periodically force flooding for unchanged LSAs 🍓

3. Backward Compatibility 🧚

Routers that support the demand circuit extensions [2] can correctly process DoNotAge LSAs flooded by routers that have the flooding reduction capability described here. They also suppress flooding DoNotAge LSAs on interfaces configured as demand circuits. BUT they will still flood DoNotAge LSAs on interfaces that aren't configured as demand circuits 👑

If there are routers in the OSPF routing domain, stub area, or NSSA area that don't support the demand circuit extensions [2], then using these flooding reduction capabilities is subject to the demand circuit interoperability constraints in section 2.5 of "Extending OSPF to Support Demand Circuits" [2]. In practice, detecting an LSA with the DC bit clear results in re-origination of self-originated DoNotAge LSAs with the DoNotAge bit clear, and purging of non-self-originated DoNotAge LSAs.

⚠️ the DC bit clear case is where the chaos happens, so keep that in mind, bestie 😭

4. Security Considerations 🔐

This memo does not create any new security issues for the OSPF protocol. Security considerations for the base OSPF protocol are covered in [1].

5. Acknowledgments 🫶

The author would like to thank Jean-Michel Esnault, Barry Friedman, Thomas Kramer, Acee Lindem, Peter Psenak, Henk Smit, and Alex Zinin for their helpful comments on this work 💜

6. Normative References 📚

[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

[2] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.

A. Configurable Parameters ⚙️

This memo defines new configuration parameters for the flooding reduction feature. The feature must be enabled by configuration on a router, and it's off by default 🙅‍♀️

flooding-reduction <all | list of interfaces>
flooding-interval <n minutes>

• flooding-reduction <all | list of interfaces> says the router has the flooding reduction feature enabled. By default it applies to all interfaces running under the OSPF instance it applies to, but it can be enabled on just a subset of explicitly specified interfaces 🦋
• flooding-interval <n minutes> sets the interval, in minutes, for periodic flooding of self-originated LSAs. By default it's 30 minutes, as per [1]. The minimum value is also 30 minutes. A value of infinity stops re-flooding of self-originated LSAs that haven't changed 💀

Author's Address 📮

Padma Pillay-Esnault
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134

EMail: ppe@cisco.com

Full Copyright Statement ©️

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all their rights.

This document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💼

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document. It also doesn't say whether any license under those rights is or isn't available, and it hasn't made any independent effort to find such rights. Info about rights in RFC documents is in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.

The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌈

Funding for the RFC Editor function is currently provided by the Internet Society.