draft-ietf-rtgwg-backoff-algo-02.txt   draft-ietf-rtgwg-backoff-algo-03.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: June 19, 2016 Orange Business Service Expires: January 5, 2017 Orange Business Service
H. Gredler H. Gredler
Private Contributor RtBrick Inc
A. Lindem A. Lindem
P. Francois P. Francois
Cisco Systems Cisco Systems
December 17, 2015 C. Bowers
Juniper Networks, Inc.
July 4, 2016
SPF Back-off algorithm for link state IGPs SPF Back-off algorithm for link state IGPs
draft-ietf-rtgwg-backoff-algo-02 draft-ietf-rtgwg-backoff-algo-03
Abstract Abstract
This document defines a standard algorithm to back-off link-state IGP This document defines a standard algorithm to back-off link-state IGP
SPF computations. SPF computations.
Having one standard algorithm improves interoperability by reducing Having one standard algorithm improves interoperability by reducing
the probability and/or duration of transient forwarding loops during the probability and/or duration of transient forwarding loops during
the IGP convergence when the IGP reacts to multiple proximate IGP the IGP convergence when the IGP reacts to multiple proximate IGP
events. events.
skipping to change at page 1, line 47 skipping to change at page 2, line 4
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 January 5, 2017.
This Internet-Draft will expire on June 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. High level goals . . . . . . . . . . . . . . . . . . . . . . 3 2. High level goals . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions and parameters . . . . . . . . . . . . . . . . . 3 3. Definitions and parameters . . . . . . . . . . . . . . . . . 4
4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 4 4. Principles of SPF delay algorithm . . . . . . . . . . . . . . 4
5. Specification of the SPF delay algorithm . . . . . . . . . . 5 5. Specification of the SPF delay state machine . . . . . . . . 5
6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. States . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 6 5.2. States Transitions . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.3. FSM Events . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security considerations . . . . . . . . . . . . . . . . . . . 7 6. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Impact on micro-loops . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 7 9. Security considerations . . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Link state IGPs, such as IS-IS [ISO10589-Second-Edition] and OSPF Link state IGPs, such as IS-IS [ISO10589-Second-Edition] and OSPF
[RFC2328], perform distributed route computation on all routers of [RFC2328], perform distributed route computation on all routers in
the area/level. In order to have consistent routing tables across the area/level. In order to have consistent routing tables across
the network, such distributed computation requires that all routers the network, such distributed computation requires that all routers
have the same version of the network topology (Link State DataBase have the same version of the network topology (Link State DataBase
(LSDB)) and perform their computation at the same time. (LSDB)) and perform their computation at the same time.
In general, when the network is stable, there is a desire to compute In general, when the network is stable, there is a desire to compute
the new SPF as soon as the failure is detected in order to quickly a new SPF as soon as a failure is detected in order to quickly route
route around the failure. However, when the network is experiencing around the failure. However, when the network is experiencing
multiple proximate failures over a short period of time, there is a multiple proximate failures over a short period of time, there is a
conflicting desire to limit the frequency of SPF computations. conflicting desire to limit the frequency of SPF computations.
Indeed, this allows a reduction in control plane resources used by Indeed, this allows a reduction in control plane resources used by
IGPs and all protocols/subsystem reacting on the attendant route IGPs and all protocols/subsystems reacting on the attendant route
change, such as LDP, RSVP-TE, BGP, Fast ReRoute computations, FIB change, such as LDP, RSVP-TE, BGP, Fast ReRoute computations, FIB
updates... This will reduce the churn on routers and in the network updates... This also reduces the churn on routers and in the network
and, in particular, reduce the side effects such as micro-loops that and, in particular, reduces the side effects such as micro-loops that
ensue during IGP convergence. ensue during IGP convergence.
To allow for this, IGPs implement a SPF back-off algorithm. To allow for this, IGPs implement an SPF back-off algorithm.
Different implementations choose different algorithms. Hence, in a However, different implementations have choosen different algorithms.
multi-vendor network, it's not possible to ensure that all routers Hence, in a multi-vendor network, it's not possible to ensure that
trigger their SPF computation after the same delay. This situation all routers trigger their SPF computation after the same delay. This
increases the average differential delay between routers completing situation increases the average differential delay between routers
their SPF computation. It also increases the probability that completing their SPF computation. It also increases the probability
different routers compute their FIBs based on a different LSDB that different routers compute their FIBs based on different LSDB
versions. Both factors increase the probability and/or duration of versions. Both factors increase the probability and/or duration of
micro-loops. micro-loops.
To allow multi-vendor networks to have all routers delay their SPF To allow multi-vendor networks to have all routers delay their SPF
computations for the same duration, this document specifies a computations for the same duration, this document specifies a
standard algorithm. Optionally, implementations may offer standard algorithm. Optionally, implementations may offer
alternative algorithms. alternative algorithms.
2. High level goals 2. High level goals
The high level goals of this algorithm are the following: The high level goals of this algorithm are the following:
o Very fast convergence for a single event (e.g., link failure). o Very fast convergence for a single event (e.g., link failure).
o Slightly paced fast convergence for multiple proximate IGP events o Paced fast convergence for multiple proximate IGP events while IGP
while IGP stability is considered acceptable. stability is considered acceptable.
o Delayed convergence when the IGP stability is problematic. This o Delayed convergence when IGP stability is problematic. This will
will allow the IGP and related processes to conserve resources allow the IGP and related processes to conserve resources during
during the period of instability. the period of instability.
o Always try to avoid different SPF_DELAY timers values across o Always try to avoid different SPF_DELAY timers values across
different routers in the area/level. Even though not all routers different routers in the area/level. Even though not all routers
will receive IGP messages at the same time (due to differences will receive IGP messages at the same time, due to differences
both in the distance from the originator of the IGP event and in both in the distance from the originator of the IGP event and in
flooding implementations). flooding implementations.
3. Definitions and parameters 3. Definitions and parameters
IGP events: An IGP LSDB change requiring a new routing table IGP events: The reception or origination of an IGP LSDB change
computation. Examples are a topology change, a prefix change, a requiring a new routing table computation. Examples are a topology
metric change on link or prefix... change, a prefix change, a metric change on a link or prefix... Note
that locally triggering a routing table computation is not considered
as an IGP event since other IGP routers are unaware of this
occurrence.
Routing table computation: computation of the routing table, by the Routing table computation: Computation of the routing table, by the
IGP, using the IGP LSDB. No distinction is made between the type of IGP, using the IGP LSDB. No distinction is made between the type of
computation performed. e.g., full SPF, incremental SPF, Partial Route computation performed. e.g., full SPF, incremental SPF, Partial Route
Computation (PRC). The type of computation is a local consideration. Computation (PRC). The type of computation is a local consideration.
This document may indifferently use the terms routing table This document may interchangeably use the terms routing table
computation or SPF computation. computation and SPF computation.
The SPF_DELAY is the delay introduced between the IGP event and the SPF_DELAY: The delay between the first IGP event triggering a new
start of the routing table computation. It can take the following routing table computation and the start of that routing table
values: computation. It can take the following values:
INITIAL_WAIT: a very small delay to quickly handle link failure, INITIAL_SPF_DELAY: A very small delay to quickly handle link
e.g., 0 milliseconds. failure, e.g., 0 milliseconds.
FAST_WAIT: a small delay to have a fast convergence in case of SHORT_SPF_DELAY: A small delay to have a fast convergence in case of
single component failure (node, SRLG..), e.g., 50-100 milliseconds. a single component failure (node, SRLG..), e.g., 50-100
Note: we want to be fast, but as this failure results in multiple milliseconds.
IGP events, being too fast increases the probability to receive
additional network events immediately after the SPF computation.
LONG_WAIT: a long delay when the IGP is unstable, e.g., 2 seconds. LONG_SPF_DELAY: A long delay when the IGP is unstable, e.g., 2
Note: Allow the IGP network to stabilize. seconds. Note that this allows the IGP network to stabilize.
The TIME_TO_LEARN timer is the maximum duration typically needed to TIME_TO_LEARN_INTERVAL: This is the maximum duration typically needed
learn all the IGP events related to a single component failure (e.g., to learn all the IGP events related to a single component failure
router failure, SRLG failure), e.g., 1 second. It's mostly dependent (e.g., router failure, SRLG failure), e.g., 1 second. It's mostly
on variation of failure detection times between all routers that are dependent on failure detection time variation between all routers
adjacent to the failure. Additionally, it may depend on the that are adjacent to the failure. Additionally, it may depend on the
different flooding implementations for routers in the network. different IGP implementations across the network, related to
origination and flooding of their link state advertisements.
The HOLD_DOWN timer is the time needed with no received IGP events HOLD_DOWN_INTERVAL: The time required with no received IGP events
before considering the IGP to be stable again, allowing the SPF_DELAY before considering the IGP to be stable again and allowing the
to be restored to INITIAL_WAIT. e.g., 3 seconds. SPF_DELAY to be restored to INITIAL_WAIT. e.g., 3 seconds.
4. Principles of SPF delay algorithm 4. Principles of SPF delay algorithm
For this first IGP event, we assume that there has been a single For this first IGP event, we assume that there has been a single
simple change in the network which can be taken into account using a simple change in the network which can be taken into account using a
single routing computation (e.g., link failure, prefix (metric) single routing computation (e.g., link failure, prefix (metric)
change) and we optimize for very fast convergence, delaying the change) and we optimize for very fast convergence, delaying the
routing computation by INITIAL_WAIT. Under this assumption, there is routing computation by INITIAL_SPF_DELAY. Under this assumption,
no benefit in delaying the routing computation. In a typical there is no benefit in delaying the routing computation. In a
network, this is the most common type of IGP event. Hence, it makes typical network, this is the most common type of IGP event. Hence,
sense to optimize this case. it makes sense to optimize this case.
If subsequent IGP events are received in a short period of time If subsequent IGP events are received in a short period of time
(TIME_TO_LEARN), we then assume that a single component failed, but (TIME_TO_LEARN_INTERVAL), we then assume that a single component
that this failure requires the knowledge of multiple IGP events in failed, but that this failure requires the knowledge of multiple IGP
order for the IGP routing to converge. Under this assumption, we events in order for IGP routing to converge. Under this assumption,
want fast convergence since this is a normal network situation. we want fast convergence since this is a normal network situation.
However, there is a benefit in waiting for all IGP events related to However, there is a benefit in waiting for all IGP events related to
this single component failure so that the IGP can compute the post- this single component failure so that the IGP can compute the post-
failure routing table in a single route computation. In this failure routing table in a single route computation. In this
situation, we delay the routing computation by FAST_WAIT. situation, we delay the routing computation by LONG_WAIT.
If IGP events are still received after TIME_TO_LEARN seconds from the If IGP events are still received after TIME_TO_LEARN_INTERVAL from
initial IGP event, then the network is presumably experiencing the initial IGP event received in QUIET state, then the network is
multiple independent failures and while waiting for network presumably experiencing multiple independent failures. In this case,
stability, the computations are delayed for a longer time represented while waiting for network stability, the computations are delayed for
by LONG_WAIT. This SPF_delay is kept until no IGP events are a longer time represented by LONG_SPF_DELAY. This SPF delay is kept
received for HOLD_DOWN seconds. until no IGP events are received for HOLDDOWN_INTERVAL.
Note: previous SPF delay algorithms used to count the number of SPF Note that previous SPF delay algorithms used to count the number of
computations. However, as all routers may receive the IGP events at SPF computations. However, as all routers may receive the IGP events
different times, we cannot assume that all routers will perform the at different times, we cannot assume that all routers will perform
same number of SPF computations or that they will schedule them at the same number of SPF computations or that they will schedule them
the same time. For example, assuming that the SPF delay is 50 ms, at the same time. For example, assuming that the SPF delay is 50 ms,
router R1 may receive 3 IGP events (E1, E2, E3) in those 50 ms and router R1 may receive 3 IGP events (E1, E2, E3) in those 50 ms and
hence will perform a single routing computation. While another hence will perform a single routing computation. While another
router R2 may only receive 2 events (E1, E2) in those 50 ms and hence router R2 may only receive 2 events (E1, E2) in those 50 ms and hence
will schedule another routing computation when receiving E3. That's will schedule another routing computation when receiving E3. That's
why this document defines a time (TIME_TO_LEARN) from the initial why this document uses a time (TIME_TO_LEARN) from the initial event
event detection/reception as opposed to defining the number of SPF detection/reception as opposed to counting the number of SPF
computations to determine when the IGP is unstable. computations to determine when the IGP is unstable.
5. Specification of the SPF delay algorithm 5. Specification of the SPF delay state machine
When no IGP events have occurred during the HOLD_DOWN interval: 5.1. States
o The IGP is set to the QUIET state. This section describes the state machine. The naming and semantics
of each state corresponds directly to the SPF delay used for IGP
events received in that state. Three states are defined:
When the IGP is in the QUIET state and an IGP event is received: QUIET: This is the initial state, when no IGP events have occured for
at least HOLDDOWN_INTERVAL since the previous routing table
computation. The state is meant to handle link failures very
quickly.
o The time of this first IGP event is stored in FIRST_EVENT_TIME. SHORT_WAIT: State entered when an IGP event has been received in
QUIET state and exited when no IGP events have been received for
HOLDDOWN_TIMER. This state is meant to handle single component
failure requiring multiple IGP events (e.g., node, SRLG).
o The next routing table computation is scheduled at: this IGP event LONG_WAIT: State reached after TIME_TO_LEARN_INTERVAL. In other
received time + INITIAL_WAIT. words, state reached after TIME_TO_LEARN_INTERVAL in state
SHORT_WAIT. This state is meant to handle multiple independent
component failures during periods of IGP instability.
o The IGP is set to the FAST_WAIT state. 5.2. States Transitions
When the IGP is in the FAST_WAIT state and an IGP event is received: The FSM is initialized to the QUIET_STATE with all three timers
deactivated. The following diagram describes briefly the state
transitions.
o If more than the TIME_TO_LEARN interval has passed since +-------------------+
FIRST_EVENT_TIME, then the IGP is set to the HOLD_DOWN state. | |<-------------------+
| QUIET | |
| |<---------+ |
+-------------------+ | |
| | |
| | |
| 1: IGP event | |
| | |
v | |
+-------------------+ | |
+---->| | | |
| | SHORT_WAIT |----->----+ |
+-----| | |
2: +-------------------+ 6: HOLDDOWN_TIMER |
IGP event | expiration |
| |
| |
| 3: LEARN_TIMER |
| expiration |
| |
v |
+-------------------+ |
+---->| | |
| | LONG_WAIT |------------>-------+
+-----| |
4: +-------------------+ 5: HOLDDOWN_TIMER
IGP event expiration
o If a routing table computation is not already scheduled, one is Figure 1: State Machine
scheduled at: this IGP event received time + FAST_WAIT.
When the IGP is in the HOLD_DOWN state and an IGP event is received: 5.3. FSM Events
o If a routing table computation is not already scheduled, one is This section describes the events and the actions performed in
scheduled at: this IGP event received time + LONG_WAIT. response.
Event 1: IGP events, while in QUIET_STATE.
Actions on event 1:
o If SPF_TIMER is not already running, start it with value
INITIAL_SPF_DELAY.
o Start LEARN_TIMER with TIME_TO_LEARN_INTERVAL.
o Start HOLDDOWN_TIMER with HOLDDOWN_INTERVAL.
o Transition to SHORT_WAIT state.
Event 2: IGP events, while in SHORT_WAIT.
Actions on event 2:
o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
o If SPF_TIMER is not already running, start it with value
SHORT_SPF_DELAY.
o Remain in current state.
Event 3: LEARN_TIMER expiration.
Actions on event 3:
o Transition to LONG_WAIT state.
Event 4: IGP events, while in LONG_WAIT.
Actions on event 4:
o Reset HOLDDOWN_TIMER to HOLDDOWN_INTERVAL.
o If SPF_TIMER is not already running, start it with value
LONG_SPF_DELAY.
o Remain in current state.
Event 5: HOLDDOWN_TIMER expiration, while in LONG_WAIT.
Actions on event 5:
o Transition to QUIET state.
Event 6: HOLDDOWN_TIMER expiration, while in SHORT_WAIT.
Actions on event 6:
o Deactivate LEARN_TIMER.
o Transition to QUIET state.
6. Parameters 6. Parameters
All the parameters MUST be configurable. All the delays All the parameters MUST be configurable. All the delays
(INITIAL_WAIT, FAST_WAIT, LONG_WAIT, TIME_TO_LEARN, HOLD_DOWN) SHOULD (INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY,
be configurable at the millisecond granularity. They MUST be TIME_TO_LEARN_INTERVAL, HOLD_DOWN_INTERVAL) SHOULD be configurable at
configurable at least at the tenth of second granularity. The the millisecond granularity. They MUST be configurable at least at
configurable range for all the parameters SHOULD be at least from 0 the tenth of second granularity. The configurable range for all the
milliseconds to 60 seconds. parameters SHOULD at least be from 0 milliseconds to 60 seconds.
This document does not propose default values for the parameters This document does not propose default values for the parameters
because these values are expected to be context dependent. because these values are expected to be context dependent.
Implementations are free to propose their own default values. Implementations are free to propose their own default values.
When setting the (default) values, one SHOULD consider the customer's When setting (default) values, one SHOULD consider the customers and
or their applications' 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 (e.g., BGP, PCEP, Traffic Engineering CSPF, Fast ReRoute IGP SPF (e.g., BGP, PCEP, Traffic Engineering CSPF, Fast ReRoute
computations). computations).
Note that some or all of these factors may change over the life of Note that some or all of these factors may change over the life of
the network. In case of doubt, it's RECOMMENDED to play it safe and the network. In case of doubt, it's RECOMMENDED to play it safe and
start with safe, i.e., longer timers. start with safe, i.e., longer timers.
skipping to change at page 6, line 46 skipping to change at page 9, line 13
values. values.
7. Impact on micro-loops 7. Impact on micro-loops
Micro-loops during IGP convergence are due to a non-synchronized or Micro-loops during IGP convergence are due to a non-synchronized or
non-ordered update of the forwarding information tables (FIB) non-ordered update of the forwarding information tables (FIB)
[RFC5715] [RFC6976] [I-D.ietf-rtgwg-spf-uloop-pb-statement]. FIBs [RFC5715] [RFC6976] [I-D.ietf-rtgwg-spf-uloop-pb-statement]. FIBs
are installed after multiple steps such as SPF wait time, SPF are installed after multiple steps such as SPF wait time, SPF
computation, FIB distribution, and FIB update. This document only computation, FIB distribution, and FIB update. This document only
addresses the first contribution. This standardized procedure addresses the first contribution. This standardized procedure
reduces the probability and/or duration of micro-loops when the IGP reduces the probability and/or duration of micro-loops when IGPs
experience multiple proximate events. It does not prevent all micro- experience multiple proximate events. It does not prevent all micro-
loops. However, it is beneficial and its cost seems limited compared loops. However, it is beneficial and is less complex and costly to
to full solutions such as [RFC5715] or [RFC6976]. implement when compared to full solutions such as [RFC5715] or
[RFC6976].
8. IANA Considerations 8. IANA Considerations
No IANA actions required. No IANA actions required.
9. Security considerations 9. Security considerations
This algorithm presented in this document does not in any way The algorithm presented in this document does not compromise IGP
compromise the security of the IGP. In fact, the HOLD_DOWN state may security. An attacker having the ability to generate IGP events
mitigate the effects of Denial-of-Service (DOS) attacks generating would be able to delay the IGP convergence time. The LONG_SPF_DELAY
many IGP events. state may help mitigate the effects of Denial-of-Service (DOS)
attacks generating many IGP events.
10. Acknowledgements 10. Acknowledgements
We would like to acknowledge Les Ginsberg, Uma Chunduri, and Mike We would like to acknowledge Les Ginsberg, Uma Chunduri, and Mike
Shand for the discussions and comments related to this document. Shand for the discussions and comments related to this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 8, line 15 skipping to change at page 10, line 31
[RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C., [RFC6976] Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
Francois, P., and O. Bonaventure, "Framework for Loop-Free Francois, P., and O. Bonaventure, "Framework for Loop-Free
Convergence Using the Ordered Forwarding Information Base Convergence Using the Ordered Forwarding Information Base
(oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
2013, <http://www.rfc-editor.org/info/rfc6976>. 2013, <http://www.rfc-editor.org/info/rfc6976>.
Authors' Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
Orange Orange
38 rue du General Leclerc
Issy Moulineaux cedex 9 92794
France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Business Service Orange Business Service
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Hannes Gredler Hannes Gredler
Private Contributor RtBrick Inc
Email: hannes@gredler.at
Email: hannes@rtbrick.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
Pierre Francois Pierre Francois
Cisco Systems Cisco Systems
Email: pifranco@cisco.com Email: pifranco@cisco.com
Chris Bowers
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: cbowers@juniper.net
 End of changes. 53 change blocks. 
123 lines changed or deleted 219 lines changed or added

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