draft-ietf-rtgwg-backoff-algo-09.txt   draft-ietf-rtgwg-backoff-algo-10.txt 
Network Working Group B. Decraene Network Working Group B. Decraene
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track S. Litkowski Intended status: Standards Track S. Litkowski
Expires: August 31, 2018 Orange Business Service Expires: September 20, 2018 Orange Business Service
H. Gredler H. Gredler
RtBrick Inc RtBrick Inc
A. Lindem A. Lindem
Cisco Systems Cisco Systems
P. Francois P. Francois
C. Bowers C. Bowers
Juniper Networks, Inc. Juniper Networks, Inc.
February 27, 2018 March 19, 2018
SPF Back-off Delay algorithm for link state IGPs SPF Back-off Delay algorithm for link state IGPs
draft-ietf-rtgwg-backoff-algo-09 draft-ietf-rtgwg-backoff-algo-10
Abstract Abstract
This document defines a standard algorithm to temporarily postpone or This document defines a standard algorithm to temporarily postpone or
'back-off' link-state IGP Shortest Path First (SPF) computations. 'back-off' link-state IGP Shortest Path First (SPF) computations.
This reduces the computational load and churn on IGP nodes when This reduces the computational load and churn on IGP nodes when
multiple temporally close network events trigger multiple SPF multiple temporally close network events trigger multiple SPF
computations. computations.
Having one standard algorithm improves interoperability by reducing Having one standard algorithm improves interoperability by reducing
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 31, 2018. This Internet-Draft will expire on September 20, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 5 4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 5
5. Specification of the SPF delay state machine . . . . . . . . 6 5. Specification of the SPF delay state machine . . . . . . . . 6
5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 6 5.1. State Machine . . . . . . . . . . . . . . . . . . . . . . 6
5.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. State . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Timers . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.4. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 8 5.4. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 8
6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 11 7. Partial Deployment . . . . . . . . . . . . . . . . . . . . . 11
8. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 11 8. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security considerations . . . . . . . . . . . . . . . . . . . 11 10. Security considerations . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . 12 12.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Link state IGPs, such as IS-IS [ISO10589-Second-Edition], OSPF Link state IGPs, such as IS-IS [ISO10589-Second-Edition], OSPF
[RFC2328] and OSPFv3 [RFC5340], perform distributed route computation [RFC2328] and OSPFv3 [RFC5340], perform distributed route computation
skipping to change at page 4, line 25 skipping to change at page 4, line 25
3. Definitions and parameters 3. Definitions and parameters
IGP events: The reception or origination of an IGP LSDB change IGP events: The reception or origination of an IGP LSDB change
requiring a new routing table computation. Examples are a topology requiring a new routing table computation. Examples are a topology
change, a prefix change and a metric change on a link or prefix. change, a prefix change and a metric change on a link or prefix.
Note that locally triggering a routing table computation is not Note that locally triggering a routing table computation is not
considered as an IGP event since other IGP routers are unaware of considered as an IGP event since other IGP routers are unaware of
this occurrence. this occurrence.
Routing table computation: Computation of the routing table, by the Routing table computation, in this document, is scoped to the IGP.
IGP implementation, using the IGP LSDB. No distinction is made So this is the computation of the IGP RIB, performed by the IGP,
between the type of computation performed. e.g., full SPF, using the IGP LSDB. No distinction is made between the type of
incremental SPF, Partial Route Computation (PRC). The type of computation performed. e.g., full SPF, incremental SPF, Partial Route
computation is a local consideration. This document may Computation (PRC): the type of computation is a local consideration.
interchangeably use the terms routing table computation and SPF This document may interchangeably use the terms routing table
computation. computation and SPF computation.
SPF_DELAY: The delay between the first IGP event triggering a new SPF_DELAY: The delay between the first IGP event triggering a new
routing table computation and the start of that routing table routing table computation and the start of that routing table
computation. It can take the following values: computation. It can take the following values:
INITIAL_SPF_DELAY: A very small delay to quickly handle a single INITIAL_SPF_DELAY: A very small delay to quickly handle a single
isolated link failure, e.g., 0 milliseconds. isolated link failure, e.g., 0 milliseconds.
SHORT_SPF_DELAY: A small delay to provide fast convergence in the SHORT_SPF_DELAY: A small delay to provide fast convergence in the
case of a single component failure (node, Shared Risk Link Group case of a single component failure (node, Shared Risk Link Group
skipping to change at page 10, line 25 skipping to change at page 10, line 25
o Remain in current state. o Remain in current state.
6. Parameters 6. Parameters
All the parameters MUST be configurable at the protocol instance All the parameters MUST be configurable at the protocol instance
granularity. They MAY be configurable at the area/level granularity. granularity. They MAY be configurable at the area/level granularity.
All the delays (INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, All the delays (INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY,
TIME_TO_LEARN_INTERVAL, HOLDDOWN_INTERVAL) SHOULD be configurable at TIME_TO_LEARN_INTERVAL, HOLDDOWN_INTERVAL) SHOULD be configurable at
the millisecond granularity. They MUST be configurable at least at the millisecond granularity. They MUST be configurable at least at
the tenth of second granularity. The configurable range for all the the tenth of second granularity. The configurable range for all the
parameters SHOULD at least be from 0 milliseconds to 60 seconds. parameters SHOULD at least be from 0 milliseconds to 60 seconds. The
HOLDDOWN_INTERVAL MUST be defaulted or configured to be longer than
the TIME_TO_LEARN_INTERVAL.
This document does not propose default values for the parameters If this SPF backoff algorithm is enabled by default, then in order to
because these values are expected to be context dependent. have consistent SPF delays between implementations with default
Implementations are free to propose their own default values. configuration, the following default values SHOULD be implemented:
However the HOLDDOWN_INTERVAL MUST be defaulted or configured to be INITIAL_SPF_DELAY 50 ms, SHORT_SPF_DELAY 200ms, LONG_SPF_DELAY: 5
longer than the TIME_TO_LEARN_INTERVAL. 000ms, TIME_TO_LEARN_INTERVAL 500ms, HOLDDOWN_INTERVAL 10 000ms.
In order to satisfy the goals stated in Section 2, operators are In order to satisfy the goals stated in Section 2, operators are
RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY RECOMMENDED to configure delay intervals such that INITIAL_SPF_DELAY
<= SHORT_SPF_DELAY and SHORT_SPF_DELAY <= LONG_SPF_DELAY. <= SHORT_SPF_DELAY and SHORT_SPF_DELAY <= LONG_SPF_DELAY.
When setting (default) values, one should consider the customers and When setting (default) values, one should consider the customers and
their application requirements, the computational power of the their application requirements, the computational power of the
routers, the size of the network, and, in particular, the number of routers, the size of the network, and, in particular, the number of
IP prefixes advertised in the IGP, the frequency and number of IGP IP prefixes advertised in the IGP, the frequency and number of IGP
events, the number of protocols reactions/computations triggered by events, the number of protocols reactions/computations triggered by
IGP SPF computation (e.g., BGP, PCEP, Traffic Engineering CSPF, Fast IGP SPF computation (e.g., BGP, PCEP, Traffic Engineering CSPF, Fast
ReRoute computations). ReRoute computations). Note that some or all of these factors may
change over the life of the network. In case of doubt, it's
Note that some or all of these factors may change over the life of RECOMMENDED that timer intervals should be chosen conservatively
the network. In case of doubt, it's RECOMMENDED that timer intervals (i.e., longer timer values).
should be chosen conservatively (i.e., longer timer values).
For the standard algorithm to be effective in mitigating micro-loops, For the standard algorithm to be effective in mitigating micro-loops,
it is RECOMMENDED that all routers in the IGP domain, or at least all it is RECOMMENDED that all routers in the IGP domain, or at least all
the routers in the same area/level, have exactly the same configured the routers in the same area/level, have exactly the same configured
values. values.
7. Partial Deployment 7. Partial Deployment
In general, the SPF Back-off Delay algorithm is only effective in In general, the SPF Back-off Delay algorithm is only effective in
mitigating micro-loops if it is deployed, with the same parameters, mitigating micro-loops if it is deployed, with the same parameters,
 End of changes. 9 change blocks. 
23 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/