Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: November 2001 Filename: draft-giacalone-metric-auto-decay- May 2001 routing-01.txt OSPFv2 Metric Auto-Decay This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This memo specifies mechanisms for automatically decaying OSPFv2 [1] metrics and priorities in the event of partial, but critical, system failures (errors) which do not cause interfaces to change state (i.e. they are opaque to transient to data). The mechanisms defined in this document, called metric auto-decay, allow operators to configure OSPFv2 networks to gracefully bypass devices which have incurred these opaque system errors. Please send comments to ospf@discuss.microsoft.com. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Table of Contents 1 Overview ............................................ 2 Basic Functionality ................................. 3 Interface Metric Decay ............................... Expires November 2001 [Page 1] Internet Draft Metric Auto-Decay May, 2001 4 Designated Router Priority Decay ..................... 5 Metric and DR Priority restoration ................... 6 Initiating Decay Sequences ........................... 7 Network Operation Issues ............................. 8 Acknowledgements ..................................... 9 References ........................................... A Compatibility ........................................ B Security Considerations .............................. C Authors' Addresses ................................... D Full Copyright Statement.............................. 1 Overview Metric Auto-decay allows OSPFv2 devices and links to become less likely to be included in shortest paths when opaque system errors occur. In opaque error scenarios, a device can still forward data, and appears as a valid neighbor, but is in a compromised state. Using Metric Auto-Decay, the network can re-configure itself so that data is biased around the semi-failed device. Examples of opaque errors include a power, control plain or environmental module failures. Although redundant systems may provide continued operation in such a state, network operators may, as policy, opt to bias traffic around partially failed devices. This memo outlines several variations of Metric Auto-decay operation, in which interface metrics are automatically increased and Designated Router (DR) priorities are manipulated. Note that Metric Auto-Decay must be configurable as a device-wide option for compliance with this memo. 2 Basic Functionality Metric Auto-decay is enabled as a configurable option. Metric Auto- Decay includes both interface metric decay and DR priority decay. Note that it must be possible to configure interface metric decay and DR priority decay independently. 3 Interface Metric Decay Single Stage Interface Metric Decay Functionality Single stage metric auto-decay increases the OSPFv2 interface metrics associated with all interfaces (and routes in boundary devices) in one step. For example, after an opaque error, a system using metric auto-decay would re-originate LSAs with metrics that have been mathematically incremented a single time. As long as the system remains in the semi failed state, metrics will remain at the increased value, and will not automatically increase thereafter. Expires November 2001 [Page 2] Internet Draft Metric Auto-Decay May, 2001 Single Stage Interface Metric Decay is enabled as a configurable option within Metric Auto-Decay. Decay-Factors for single stage metric decay The Metric Auto-decay decay-factor is a configurable option which specifies the amount by which normal metrics should be increased when an opaque system error occurs. It must be possible to configure the decay-factor as an additive integer value, a multiplier, or both. Additive decay values are termed additive decay-factors and multiplicative decay values are termed decay-factor multipliers. The decay-factor type to be used must be a configurable option. The default decay-factor type is additive. For example, using single stage interface metric decay, if a device has an interface with a metric of 10, and the decay-factor is 10 (additive) or 2 (multiplicative), after a opaque system error, the metric would be increased to 20 (additive) or multiplied by 2 to equal 20. The specification of a default Decay-Factors are TBD. Single Stage Interface Metric Decay LSA Re-Origination When Metric Auto-decay is enabled, and an opaque system error occurs, the device re-originates LSAs. When using single stage interface metric decay, a single system event must cause LSAs to be re- originated only once, unless otherwise dictated by re-origination rules outside of this memo. The following LSAs should be re-originated (depending on the router's role) upon opaque system error: -Router-LSAs -Summary-LSAs -AS-external-LSAs (both E1 and E2) -Type 7 LSAs Progressive Interface Metric Decay Functionality As an optional alternative to single stage interface metric decay, progressive metric auto-decay increases OSPFv2 metrics associated with all device interfaces and routes a number of times at specific intervals for a specific period. Progressive Metric Decay is enabled through a configurable option. Decay-Factors for Progressive Metric Decay When using progressive metric decay, upon opaque system error, metrics are increased by the decay-factor every Metric Auto-decay Expires November 2001 [Page 3] Internet Draft Metric Auto-Decay May, 2001 progression-interval. The semantics of the decay-factors are the same as single stage metric decay, however, the decay progression-interval is an supplementary configurable parameter. The decay-progression interval is specified in seconds. In addition to the decay-progression interval, progressive metric decay must include a configurable time limit which specifies an overall period in which metrics are decayed. After this timer has expired, and as long as the system remains in the semi failed state, metrics will remain at the last incremented value, and will not automatically increase. This value is specified in seconds, and is called the decay-period. The decay-period's value must be divisible by the decay-progression interval. An example of additive decay-factors with progressive metric decay is an interface metric that is initially 10, and after an opaque system error, the metric is increased by the additive decay-factor of 10, to a metric value of 20. Then after progression-interval "p" it could again be increased by 10 to 30, and so on. An example of multiplicative decay-factors with progressive metric decay, would be if an interfaces metric is initially 10, after an opaque system error, the metric could be multiplied by 2 to 20. Then after progression-interval "p" it could again be multiplied by 2 to 40, and so on. Using additive or multiplicative decay-factors with progressive metric decay allows the network manager to select either linear or non-linear progressive metric decay, permitting other previously higher cost network paths to become optimal based on the time the device in question remains in the errant state. The minimum Metric Auto-decay progression-interval must be 5 seconds (the same as OSPFv2's MinLSInterval). The default metric decay progression-interval should be 5 minutes (300 seconds). The specification of a default Decay-Factors are TBD. Progressive Metric Decay LSA Re-Origination In progressive metric decay, LSAs are re-originated upon opaque error, and then every progression-interval. If for example the progression-interval is 60 seconds, the metric will increase by decay-factor every minute until decay-period is reached, and therefor LSAs must be re-originated accordingly, every 60 seconds. Expires November 2001 [Page 4] Internet Draft Metric Auto-Decay May, 2001 Separate opaque system errors must not cause multiple instances of the same LSA to be generated at the same decay-factor within the Metric Auto-decay progression interval. All other re-origination semantics are as in single stage metric decay LSA Re-Origination. 4 Designated Router Priority Decay As a configurable option within Metric Auto-decay, DR priority Decay reduces router priority to zero, in order to force the router to become ineligible to be the DR, or otherwise for election. Although signaled in other packets, LSA re-origination during/after DR change must remain as in [1]. 5 Metric and DR Priority restoration It must be possible to accomplish metric and DR priority restoration through the issuance of an operator initiated configuration command. Network operators must not be required to re-configure metrics or priorities; implementations must store data pertaining to original metric and priority values for this purpose. It may also possible to use automatic metric and DR priority restoration techniques, however network stability must be considered. Mechanisms such as automatic metric and DR priority restoration should be considered a matter of further investigation. 6 Initiating Decay Sequences While this memo does not specify which events can cause a decay sequence to begin, examples include power supply, control plain, and environmental module failures, or any event which would generate "serious" Syslog messages. 7 Network Operation Issues The benefits of Metric Auto-decay (for example, interface metric decay) must be balanced with network topology and the ability of the network to handle aggregate traffic loads if Equal Cost Multipath routing is "broken". Obviously, the re-origination of LSAs can cause networks to "re-converge", and this must be taken into account by the network operator. 8 Acknowledgements 9 References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998 Expires November 2001 [Page 5] Internet Draft Metric Auto-Decay May, 2001 [2] Coltun, R., Moy, J., "OSPF for IPv6" RFC 2740, December 1999 [3] Giacalone, S., "Network Engineering Extensions to OSPFv3" work in progress (independent Internet Draft). A Compatibility The use of Metric Auto-decay does not create compatibility issues with devices that do not support the feature. B Security Considerations Metric Auto-decay does not appear to provide risk in addition to that already present in routing protocols to which it may be applied. C Authors' Addresses Spencer Giacalone Predictive Systems, Inc. 25a Vreeland Road Florham Park, NJ 07932 Phone: +1 (973) 301-5695 EMail: spencer.giacalone@predictive.com D Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 Expires November 2001 [Page 6] Internet Draft Metric Auto-Decay May, 2001 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires November 2001 [Page 7]