Internet DRAFT - draft-giacalone-metric-auto-decay-routing
draft-giacalone-metric-auto-decay-routing
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]
