Network Working Group S. Giacalone INTERNET-DRAFT Predictive Systems Expiration Date: January 2001 Filename: draft-giacalone-metric-auto-decay-routing-00.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 router priorities in the event of partial, but potentially critical, system failures which do not cause interfaces to change basic state (they are opaque to transient data). These procedures, called metric auto-decay, allow OSPFv2 networks to gracefully bypass devices which have incurred partial/opaque system failures. Please send comments to ospf@discuss.microsoft.com. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Table of Contents Overview .............................................. Terminology ........................................... Basic Functionality ................................... Expires February 2001 [Page 1] Internet Draft Metric Auto-Decay August, 2000 Acknowledgements ...................................... References ............................................ Compatibility ......................................... Security Considerations ............................... Authors' Addresses .................................... Full Copyright Statement .............................. Overview Metric Auto-decay allows OSPFv2 devices to appear less desirable for data forwarding when partial/opaque system errors occur. In partial/ opaque error scenarios a device can still forward data, but is in a compromised state. Using Metric Auto-Decay, the network can configure itself so that data can be biased around the semi-failed device. Partial/opaque errors might include (but are not limited to) power supply, control plain or environmental module failures. Metric Auto-decay is the functional OSPFv2 equivalent of the System Failure Node TLV in [3] for OSPFv3 [2]. This memo outlines a number of ways that Metric Auto-decay can be used to automatically increase interface metrics and Designated Router (DR) priorities. Note that Metric Auto Decay is configured as a device option as are its many features and parameters. Basic Functionality Metric Auto-decay is enabled through a configurable option. Metric Auto-Decay includes both interface metric decay and DR Priority decay. 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 related to a device one time. For example, if a system's environmental module fails, that system would re-originate LSAs with metrics that have been incremented a single time. Single Stage Interface Metric Decay is enabled through 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 Expires January 2001 [Page 2] Internet Draft Metric Auto-Decay August, 2000 a partial/opaque failure occurs. The decay-factor can be configured as either an integer value by which initial metrics will be increased (additive) or a multiplier. Additive decay variables are termed additive decay-factors. Multiplicative decay variables are termed decay-factor multiplier. Together, the styles of decay-factors are called decay-factor types. The decay-factor type to be used is specified as a configurable option. The default decay-factor type is additive. Note that these basic Decay-Factor semantics will be used throughout this memo. An example of how decay-factors work with single stage interface metric decay is if a device has an interfaces with a metric of 10, and the decay-factor is 10 (additive) or 2 (multiplicative), after a partial/opaque system failure, 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 a partial/opaque system error occurs, the device re-originates LSA. When using single stage interface metric decay, a single system event must cause LSAs to be re-originated only once, unless dictated by LSA outside re- origination procedures (transmission intervals, acknowledgment, etc) as per [1]. The following LSAs should be re-originated (depending on the router's role) upon partial/opaque device failure: -Router-LSAs -Summary-LSAs -AS-external-LSAs (both E1 and E2) -Type 7 Progressive Interface Metric Decay Functionality Progressive metric auto-decay increases OSPFv2 metrics associated with all device interfaces and routes a number of times at specific intervals for specific period. Progressive Metric Decay is enabled through a configurable option. Decay-Factors for Progressive Metric Decay When using progressive metric decay, upon partial/opaque system failure, metrics are increased by decay-factor every Metric Auto- decay progression-interval. Although the semantics of the decay- factors are the same as in single stage metric decay, the decay Expires January 2001 [Page 3] Internet Draft Metric Auto-Decay August, 2000 progression-interval is an additional configurable parameter. The decay-progression interval is specified in seconds. Additionally, progressive metric decay adds a configurable value to limit the overall time period over which metrics are decayed. 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. To give an example of additive decay-factors with progressive metric decay, if an interface's metric is initially 10, after a partial/opaque system failure, the metric could be increased by 10 to 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 a partial/opaque system failure, 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. The minimum Metric Auto-decay progression-interval is 5 seconds (the same as OSPFv2's MinLSInterval). The default metric decay progression-interval is 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 every progression-interval. For example if the progression-interval is 1 minute (specified in seconds), the metric will increase by decay-factor every minute until decay-period is reached, and therefor LSAs must be re-originated accordingly. Partial/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 semantics are as in single stage metric decay LSA Re- Origination. Designated Router Priority Decay Expires January 2001 [Page 4] Internet Draft Metric Auto-Decay August, 2000 Designated router priority decay allows a designated router (DR) to decay (increase) it's DR priority in the event of an partial/opaque system failure. Semantic designated router priority decay functionality is the same as in single stage and progressive metric decay. Obviously, though, the metric being changed (the DR priority) is different. The use Designated Router Priority Decay is configured as an option within Metric Auto-decay. LSA re-origination during/after DR change remains as in [1]. Metric/Priority restoration Metric/priority restoration will be accomplished through the issuance of an operator initiated configuration command. Network operators must not be required to re-apply metrics or priorities; implementations must store data pertaining to their original values. It is also possible to use automatic metric/priority restoration techniques, however network stability must be considered. Techniques such as automatic progress metric/priority restoration should be investigated (see progressive metric decay for operational semantics). Initiating Metric Decay While this memo does not specify events that may cause a metric decay sequence to begin, examples include power supply, control plain or environmental module failure and/or any event which would generate serious Syslog messages. Network Operation Issues The benefits of Metric Auto-decay (in this case, 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". Acknowledgements References [1] Moy, J., "OSPF Version 2", RFC 2328, April 1998 [2] Coltun, R., Moy, J., "OSPF for IPv6" RFC 2740, December 1999 [3] Giacalone, S., "Network Engineering Extensions to OSPFv3" work in Expires January 2001 [Page 5] Internet Draft Metric Auto-Decay August, 2000 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 (2000). 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires January 2001 [Page 6]