idnits 2.17.1 draft-pillay-esnault-ospf-flooding-07.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Padma Pillay-Esnault 3 Internet Draft Juniper Networks 4 June 2003 5 Category: Informational 6 Expires: December 2003 8 OSPF Refresh and Flooding Reduction in Stable Topologies 10 draft-pillay-esnault-ospf-flooding-07.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2002). All Rights Reserved. 37 1. Abstract 39 This document describes an extension to the OSPF protocol to 40 reduce periodic flooding of Link State Advertisements in 41 stable topologies. 43 The OSPF current behavior requires that all LSAs other than DoNotAge 44 LSAs to be refreshed every 30 minutes. This document proposes to 45 generalize the use of DoNotAge LSAs to reduce protocol traffic in 46 stable topologies 48 2. Motivation 50 The explosive growth of IP based networks has placed focus on the 51 scalability of Interior Gateway Protocols such as OSPF. Networks 52 using OSPF are growing every day and will continue to expand to 53 accommodate the demand for connections to the Internet or intranets. 55 Internet Service Providers and users having large networks have 56 noticed non-negligible protocol traffic even when their network 57 topologies were stable. 59 OSPF requires every LSA to be refreshed every 1800 seconds or else 60 they will expire when they reach 3600 seconds [1]. 62 This document proposes to overcome the LSA expiration by generalizing 63 the use of DoNotAge LSAs. This technique will facilitate OSPF 64 scaling by reducing OSPF traffic overhead in stable topologies. 66 3. Changes in the existing implementation. 68 This enhancement relies on the implementation of the DoNotAge bit 69 and the Indication-LSA. The details of the implementation of 70 the DoNotAge bit and the Indication-LSA are specified in 71 "Extending OSPF to Support Demand Circuits" [2]. 73 Flooding reduction capable routers will continue to send hellos 74 to their neighbors and keep aging their self-originated LSAs in 75 their database. However, they will flood their self-originated LSAs 76 with the DoNotAge bit set. Hence, self-originated LSAs do not 77 have to be reflooded every 30 minutes and the reflooding interval 78 can be extended to the configured forced flooding interval. 79 As in normal OSPF operation, any change in the contents of the LSA 80 will cause a reoriginated LSA to be flooded with the DoNotAge bit 81 set. This will reduce protocol traffic overhead while allowing 82 changes to be flooded immediately. 84 Flooding reduction capable routers will flood received 85 non-self-originated LSAs with the DoNotAge bit set on all normal 86 or flooding-reduction only interfaces within the LSA's flooding 87 scope. If an interface is configured both as flooding-reduction 88 capable and Demand-Circuit then the flooding is done if and only if 89 the contents of the LSA have changed. This allows LSA flooding for 90 unchanged LSAs to be periodically forced by the originating router. 92 4. Backward Compatibility 94 Routers supporting the demand circuit extensions [2] will be 95 able to correctly process DoNotAge LSAs flooded by routers 96 supporting the flooding reduction capability described herein. 97 These routers will also suppress flooding DoNotAge LSAs on 98 interfaces configured as demand circuits. However, they will also 99 flood DoNotAge LSAs on interfaces which are not configured as 100 demand circuits. 102 When there are routers in the OSPF routing domain, stub area, 103 or NSSA area that do not support the demand circuit extensions [2] 104 then the use of these flooding reduction capability will be 105 subject to the demand circuit interoperability constraints 106 articulated in section 2.5 of "Extending OSPF to Support Demand 107 Circuits" [2]. This implies that detection of an LSA with the DC 108 bit clear will result in the re-origination of self-originated 109 DoNotAge LSAs with the DoNotAge clear and purging of 110 non-self-originated DoNotAge LSAs. 112 5. Security Considerations 114 This memo does not create any new security issues for the OSPF 115 protocol. Security considerations for the base OSPF protocol are 116 covered in [1]. 118 6. Intellectual Property Considerations 120 The IETF has been notified by Cisco Systems of intellectual property 121 rights claimed in regard to some or all of the specifications 122 contained in this document. For more information please refer to the 123 IETF web page http://www.ietf.org/ietf/IPR/CISCO-OSPF-REFRESH.txt 125 7. Acknowledgments 127 The author would like to thank Jean-Michel Esnault, Barry Friedman, 128 Thomas Kramer, Acee Lindem, Peter Psenak, Henk Smit and Alex Zinin 129 for their helpful comments on this work. 131 8. Normative References 133 [1] RFC 2328 OSPF Version 2. J. Moy. April 1998. 134 [2] RFC 1793 Extending OSPF to Support Demand Circuits. J. Moy. 135 April 1995. 137 A. Configurable Parameters 139 This memo defines new configuration parameters for the flooding 140 reduction feature. The feature must be enabled by configuration 141 on a router and is by default off. 143 flooding-reduction 144 Indicates that the router has flooding reduction feature 145 enabled. By default, it applies to all interfaces running 146 under the OSPF instance to which it applies. The feature 147 can be enabled on a subset of explicitly specified interfaces. 149 flooding-interval 150 Indicates the interval in minutes for the periodic flooding 151 of self-originated LSAs. By default this value is 152 30 minutes as per [1]. The minimum value is also 30 minutes. 153 A value of infinity will prevent reflooding of self-originated 154 LSAs that have not changed. 156 9. Authors' Addresses 158 Padma Pillay-Esnault 159 Juniper Networks 160 1194 N, Mathilda Avenue 161 Sunnyvale, CA 94089-1206 163 Email: padma@juniper.net