 1/draftietfbmwgigpdataplaneconvterm18.txt 20091026 21:12:13.000000000 +0100
+++ 2/draftietfbmwgigpdataplaneconvterm19.txt 20091026 21:12:13.000000000 +0100
@@ 1,21 +1,21 @@
Network Working Group S. Poretsky
InternetDraft Allot Communications
Intended status: Informational B. Imhoff
Expires: January 14, 2010 Juniper Networks
+Expires: April 29, 2010 Juniper Networks
K. Michielsen
Cisco Systems
 July 13, 2009
+ October 26, 2009
Terminology for Benchmarking LinkState IGP Data Plane Route Convergence
 draftietfbmwgigpdataplaneconvterm18
+ draftietfbmwgigpdataplaneconvterm19
Status of this Memo
This InternetDraft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
@@ 34,21 +34,21 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use InternetDrafts as reference
material or to cite them other than as "work in progress."
The list of current InternetDrafts can be accessed at
http://www.ietf.org/ietf/1idabstracts.txt.
The list of InternetDraft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
 This InternetDraft will expire on January 14, 2010.
+ This InternetDraft will expire on April 29, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/licenseinfo).
Please review these documents carefully, as they describe your rights
@@ 65,59 +65,60 @@
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
 3.2.1. Convergence Event Instant . . . . . . . . . . . . . . 6
 3.2.2. Convergence Recovery Instant . . . . . . . . . . . . . 7
 3.2.3. First Route Convergence Instant . . . . . . . . . . . 7
 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8
 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8
+ 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
+ 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7
+ 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
+ 3.2.4. First Route Convergence Instant . . . . . . . . . . . 8
+ 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9
 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 9
+ 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
 3.4.4. NextBest Egress Interface . . . . . . . . . . . . . . 10
+ 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11
+ 3.4.4. NextBest Egress Interface . . . . . . . . . . . . . . 11
3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
3.5.1. RateDerived Method . . . . . . . . . . . . . . . . . 11
 3.5.2. LossDerived Method . . . . . . . . . . . . . . . . . 12
 3.5.3. RouteSpecific LossDerived Method . . . . . . . . . . 13
+ 3.5.2. LossDerived Method . . . . . . . . . . . . . . . . . 13
+ 3.5.3. RouteSpecific LossDerived Method . . . . . . . . . . 14
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 15
 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 15
 3.6.3. RouteSpecific Convergence Time . . . . . . . . . . . 16
+ 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 16
+ 3.6.3. RouteSpecific Convergence Time . . . . . . . . . . . 17
3.6.4. LossDerived Convergence Time . . . . . . . . . . . . 18
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19
3.6.6. LossDerived Loss of Connectivity Period . . . . . . . 20
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21
 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 21
 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 21
 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 22
+ 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22
+ 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 22
+ 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23
3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23
 3.7.6. Sustained Convergence Validation Time . . . . . . . . 23
+ 3.7.6. Sustained Convergence Validation Time . . . . . . . . 24
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 24
+ 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 25
4. Security Considerations . . . . . . . . . . . . . . . . . . . 25
 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25
 7.2. Informative References . . . . . . . . . . . . . . . . . . 26
 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 27
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction and Scope
This draft describes the terminology for benchmarking LinkState
Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in [Po09a]. The
methodology to be used for this benchmarking is described in [Po09m].
The purpose of this document is to introduce new terms required to
complete execution of the IGP Route Methodology [Po09m].
@@ 135,21 +136,20 @@
Frame Loss Rate [Ref.[Br91], section 3.6]
Throughput [Ref.[Br91], section 3.17]
Offered Load [Ref.[Ma98], section 3.5.2]
Forwarding Rate [Ref.[Ma98], section 3.6.1]
Device Under Test (DUT) [Ref.[Ma98], section 3.1.1]
System Under Test (SUT) [Ref.[Ma98], section 3.1.2]
Outoforder Packet [Ref.[Po06], section 3.3.2]
Duplicate Packet [Ref.[Po06], section 3.3.3]
Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2]
 Flow [Ref.[Po06], section 3.1.5]
Forwarding Delay [Ref.[Po06], section 3.2.4]
Loss Period [Ref.[Ko02], section 4]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119
[Br97]. RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track
document.
@@ 230,21 +230,49 @@
Measurement Units: N/A
Issues: None
See Also:
Route Convergence, Full Convergence, Stale Forwarding
3.2. Instants
3.2.1. Convergence Event Instant
+3.2.1. Traffic Start Instant
+
+ Definition:
+
+ The time instant the Tester sends out the first data packet to the
+ DUT.
+
+ Discussion:
+
+ If using the LossDerived Method or the RouteSpecific LossDerived
+ Method to benchmark IGP convergence time, and the applied Convergence
+ Event does not cause instantaneous traffic loss for all routes at the
+ Convergence Event Instant then the Tester SHOULD collect a timestamp
+ on the Traffic Start Instant in order to measure the period of time
+ between the Traffic Start Instant and Convergence Event Instant.
+
+ Measurement Units:
+
+ hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
+ microseconds.
+
+ Issues: None
+
+ See Also:
+
+ Convergence Event Instant, RouteSpecific Convergence Time, Loss
+ Derived Convergence Time.
+
+3.2.2. Convergence Event Instant
Definition:
The time instant that a Convergence Event occurs.
Discussion:
If the Convergence Event causes instantaneous traffic loss on the
Preferred Egress Interface, the Convergence Event Instant is
observable from the data plane as the instant that the DUT begins to
@@ 255,21 +283,21 @@
Measurement Units:
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.
Issues: None
See Also: Convergence Event
3.2.2. Convergence Recovery Instant
+3.2.3. Convergence Recovery Instant
Definition:
The time instant that Full Convergence has completed.
Discussion:
The Full Convergence completed state MUST be maintained for an
interval of duration equal to the Sustained Convergence Validation
Time in order to validate the Convergence Recovery Instant.
@@ 287,21 +315,21 @@
hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
microseconds.
Issues: None
See Also:
Sustained Convergence Validation Time, Full Convergence
3.2.3. First Route Convergence Instant
+3.2.4. First Route Convergence Instant
Definition:
The time instant the first route entry completes Route Convergence
following a Convergence Event
Discussion:
Any route may be the first to complete Route Convergence. The First
Route Convergence Instant is observable from the data plane as the
@@ 457,68 +485,71 @@
Definition:
The method to calculate convergence time benchmarks from observing
Forwarding Rate each Packet Sampling Interval.
Discussion:
Figure 1 shows an example of the Forwarding Rate change in time
during convergence as observed when using the RateDerived Method.
 ^ Convergence
 Fwd  Recovery
 Rate  Instant
  Offered ^
+ ^ Traffic Convergence
+ Fwd  Start Recovery
+ Rate  Instant Instant
+  Offered ^ ^
 Load > \ /
 \ /< Convergence
 \ Packet / Recovery
 Convergence >\ Loss / Transition
 Event \ /
 Transition \/ < Max Packet Loss

+>
^ ^ time
Convergence First Route
Event Instant Convergence Instant
Figure 1: RateDerived Convergence Graph
 The Offered Load SHOULD consists of a single Stream [Po06]. If
+ The Offered Load SHOULD consist of a single Stream [Po06]. If
sending multiple Streams, the measured traffic rate statistics for
all Streams MUST be added together.
The destination addresses for the Offered Load MUST be distributed
 such that all routes in the FIB are matched and each route is offered
 an equal share of the total Offered Load.
+ such that all routes or a statistically representative subset of all
+ routes are matched and each of these routes is offered an equal share
+ of the Offered Load. It is RECOMMENDED to send traffic to all
+ routes, but a statistically representative subset of all routes can
+ be used if required.
 At least one packet per route in the FIB for all routes in the FIB
 MUST be offered to the DUT within each Packet Sampling Interval.
+ At least one packet per route for all routes matched in the Offered
+ Load MUST be offered to the DUT within each Packet Sampling Interval.
The Offered Load, the number of routes, and the Packet Sampling
Interval influence the observations for the RateDerived Method. It
may be difficult to identify the different convergence time instants
in the RateDerived Convergence Graph. For example, it is possible
that a Convergence Event causes the Forwarding Rate to drop to zero,
while this may not be observed in the Forwarding Rate measurements if
 the Packet Sampling Interval is too high.
+ the Packet Sampling Interval is too large.
Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss.
RateDerived Method is a RECOMMENDED method to measure convergence
time benchmarks.
To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect a timestamp of
the Convergence Event Instant and the Tester SHOULD observe
 Forwarding Rate seperately on the NextBest Egress Interface.
+ Forwarding Rate separately on the NextBest Egress Interface.
Since the RateDerived Method does not distinguish between individual
traffic destinations, it SHOULD NOT be used for any route specific
measurements. Therefor RateDerived Method SHOULD NOT be used to
benchmark Route Loss of Connectivity Period.
Measurement Units: N/A
Issues: None
@@ 530,43 +561,46 @@
3.5.2. LossDerived Method
Definition:
The method to calculate the LossDerived Convergence Time and Loss
Derived Loss of Connectivity Period benchmarks from the amount of
packet loss.
Discussion:
 The Offered Load SHOULD consists of a single Stream [Po06]. If
+ The Offered Load SHOULD consist of a single Stream [Po06]. If
sending multiple Streams, the measured traffic rate statistics for
all Streams MUST be added together.
The destination addresses for the Offered Load MUST be distributed
 such that all routes in the FIB are matched and each route is offered
 an equal share of the total Offered Load.
+ such that all routes or a statistically representative subset of all
+ routes are matched and each of these routes is offered an equal share
+ of the Offered Load. It is RECOMMENDED to send traffic to all
+ routes, but a statistically representative subset of all routes can
+ be used if required.
LossDerived Method SHOULD always be combined with RateDerived
Method in order to observe Full Convergence completion. The total
amount of Convergence Packet Loss is collected after Full Convergence
completion.
To measure convergence time and loss of connectivity benchmarks, the
Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss).
To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the
 Convergence Event Instant, the Tester SHOULD collect a timestamp of
 the Convergence Event Instant and the Tester SHOULD observe packet
 loss seperately on the NextBest Egress Interface (Convergence Packet
 Loss).
+ Convergence Event Instant, the Tester SHOULD collect timestamps of
+ the Start Traffic Instant and of the Convergence Event Instant, and
+ the Tester SHOULD observe packet loss separately on the NextBest
+ Egress Interface (Convergence Packet Loss).
Since LossDerived Method does not distinguish between traffic
destinations and the packet loss statistics are only collected after
Full Convergence completion, this method can only be used to measure
average values over all routes. For these reasons LossDerived
Method can only be used to benchmark LossDerived Convergence Time
and LossDerived Loss of Connectivity Period.
Note that the LossDerived Method measures an average over all
routes, including the routes that may not be impacted by the
@@ 588,41 +622,42 @@
The method to calculate the RouteSpecific Convergence Time benchmark
from the amount of packet loss during convergence for a specific
route entry.
Discussion:
To benchmark RouteSpecific Convergence Time, the Tester provides an
Offered Load that consists of multiple Streams [Po06]. Each Stream
has a single destination address matching a different route entry,
 for every route entry in the FIB. Convergence Packet Loss is
 measured for each Stream separately.
+ for all routes or a statistically representative subset of all
+ routes. Convergence Packet Loss is measured for each Stream
+ separately.
RouteSpecific LossDerived Method SHOULD always be combined with
RateDerived Method in order to observe Full Convergence completion.
The total amount of Convergence Packet Loss for each Stream is
collected after Full Convergence completion.
RouteSpecific LossDerived Method is a RECOMMENDED method to measure
convergence time benchmarks.
To measure convergence time and loss of connectivity benchmarks, the
Tester SHOULD in general observe packet loss on all DUT egress
interfaces (Connectivity Packet Loss).
To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the
 Convergence Event Instant, the Tester SHOULD collect a timestamp of
 the Convergence Event Instant and the Tester SHOULD observe packet
 loss seperately on the NextBest Egress Interface (Convergence Packet
 Loss).
+ Convergence Event Instant, the Tester SHOULD collect timestamps of
+ the Start Traffic Instant and of the Convergence Event Instant, and
+ the Tester SHOULD observe packet loss separately on the NextBest
+ Egress Interface (Convergence Packet Loss).
Since RouteSpecific LossDerived Method uses traffic streams to
individual routes, it measures packet loss as it would be experienced
by a network user. For this reason RouteSpecific LossDerived
Method is RECOMMENDED to measure RouteSpecific Convergence Time
benchmarks and Route Loss of Connectivity Period benchmarks.
Measurement Units: seconds
Issues: None
@@ 735,33 +770,33 @@
each measured route. The calculation is equal to Equation 7 in
Section 3.6.5.
RouteSpecific Convergence Time =
Connectivity Packet Loss for specific route/Offered Load per route
Equation 3
If the applied Convergence Event does not cause instantaneous traffic
loss for all routes at the Convergence Event Instant, then the Tester
 SHOULD collect a timestamp of the Convergence Event Instant and the
 Tester SHOULD observe Convergence Packet Loss separately on the Next
 Best Egress Interface. When benchmarking RouteSpecific Convergence
 Time, Convergence Packet Loss is measured and Equation 4 is applied
 for each measured route.
+ SHOULD collect timestamps of the Traffic Start Instant and of the
+ Convergence Event Instant, and the Tester SHOULD observe Convergence
+ Packet Loss separately on the NextBest Egress Interface. When
+ benchmarking RouteSpecific Convergence Time, Convergence Packet Loss
+ is measured and Equation 4 is applied for each measured route.
RouteSpecific Convergence Time =
Convergence Packet Loss for specific route/Offered Load per route
  (Convergence Event Instant  start traffic instant)
+  (Convergence Event Instant  Traffic Start Instant)
Equation 4
 The Convergence Event Instant and start traffic instant SHOULD be
+ The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.
The RouteSpecific Convergence Time benchmarks enable minimum,
maximum, average, and median convergence time measurements to be
reported by comparing the results for the different route entries.
It also enables benchmarking of convergence time when configuring a
priority value for route entry(ies). Since multiple RouteSpecific
Convergence Times can be measured it is possible to have an array of
results. The format for reporting RouteSpecific Convergence Time is
provided in [Po09m].
@@ 794,32 +829,33 @@
Egress Interface. When benchmarking LossDerived Convergence Time,
Connectivity Packet Loss is measured and Equation 5 is applied.
LossDerived Convergence Time =
Connectivity Packet Loss/Offered Load
Equation 5
If the applied Convergence Event does not cause instantaneous traffic
loss for all routes at the Convergence Event Instant, then the Tester
 SHOULD collect a timestamp of the Convergence Event Instant and the
 Tester SHOULD observe Convergence Packet Loss separately on the Next
 Best Egress Interface. When benchmarking LossDerived Convergence
 Time, Convergence Packet Loss is measured and Equation 6 is applied.
+ SHOULD collect timestamps of the Start Traffic Instant and of the
+ Convergence Event Instant and the Tester SHOULD observe Convergence
+ Packet Loss separately on the NextBest Egress Interface. When
+ benchmarking LossDerived Convergence Time, Convergence Packet Loss
+ is measured and Equation 6 is applied.
LossDerived Convergence Time =
Convergence Packet Loss/Offered Load
  (Convergence Event Instant  start traffic instant)
+  (Convergence Event Instant  Traffic Start Instant)
Equation 6
 The Convergence Event Instant and start traffic instant SHOULD be
+ The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester.
Measurement Units: seconds
Issues: None
See Also:
Convergence Packet Loss, Connectivity Packet Loss, Route Convergence
@@ 834,21 +870,21 @@
Discussion:
In general the Route Loss of Connectivity Period is not equal to the
RouteSpecific Convergence Time. If the DUT continues to forward
traffic to the Preferred Egress Interface after the Convergence Event
is applied then the Route Loss of Connectivity Period will be smaller
than the RouteSpecific Convergence Time. This is also specifically
the case after reversing a failure event.
The Route Loss of Connectivity Period may be equal to the Route
 Specific Convergence Time, as a characteristic of the Convergence
+ Specific Convergence Time if, as a characteristic of the Convergence
Event, traffic for all routes starts dropping instantaneously on the
Convergence Event Instant. See discussion in [Po09m].
For the testcases described in [Po09m] the Route Loss of Connectivity
Period is expected to be a single Loss Period [Ko02].
When benchmarking Route Loss of Connectivity Period, Connectivity
Packet Loss is measured for each route and Equation 7 is applied for
each measured route entry. The calculation is equal to Equation 3 in
Section 3.6.3.
@@ 947,23 +983,21 @@
The number of packets that should have been forwarded by a DUT under
a constant Offered Load that were not forwarded due to lack of
resources.
Discussion:
Packet Loss is a modified version of the term "Frame Loss Rate" as
defined in [Br91]. The term "Frame Loss" is intended for Ethernet
Frames while "Packet Loss" is intended for IP packets.
 Measurement units:

 Number of offered packets that are not forwarded.
+ Measurement units: Number of offered packets that are not forwarded.
Issues: None
See Also: Convergence Packet Loss
3.7.3. Convergence Packet Loss
Definition:
The number of packets lost due to a Convergence Event until Full
@@ 1016,26 +1049,26 @@
3.7.5. Packet Sampling Interval
Definition:
The interval at which the Tester (test equipment) polls to make
measurements for arriving packets.
Discussion:
 At least one packet per route in the FIB for all routes MUST be
 offered to the DUT within the Packet Sampling Interval. Metrics
 measured at the Packet Sampling Interval MUST include Forwarding Rate
 and received packets.
+ At least one packet per route for all routes matched in the Offered
+ Load MUST be offered to the DUT within the Packet Sampling Interval.
+ Metrics measured at the Packet Sampling Interval MUST include
+ Forwarding Rate and received packets.
 Packet Sampling Interval can influence the Convergence Graph as
+ Packet Sampling Interval can influence the convergence graph as
observed with the RateDerived Method. This is particularly true
when implementations complete Full Convergence in less time than the
Packet Sampling Interval. The Convergence Event Instant and First
Route Convergence Instant may not be easily identifiable and the
RateDerived Method may produce a larger than actual convergence
time.
The recommended value for configuration of the Packet Sampling
Interval when using the RateDerived Method is provided in [Po09m].
For the other benchmark methods the value of the Packet Sampling
@@ 1054,21 +1087,22 @@
The amount of time for which the completion of Full Convergence is
maintained without additional packet loss.
Discussion:
The purpose of the Sustained Convergence Validation Time is to
produce convergence benchmarks protected against fluctuation in
Forwarding Rate after the completion of Full Convergence is observed.
The RECOMMENDED Sustained Convergence Validation Time to be used is 5
seconds. The BMWG selected 5 seconds based upon RFC 2544 [Br99]
 which recommends waiting 2 seconds for residual frames to arrive and
+ which recommends waiting 2 seconds for residual frames to arrive
+ (this is the Forwarding Delay threshold for the last packet sent) and
5 seconds for DUT restabilization.
Measurement Units: seconds
Issues: None
See Also:
Full Convergence, Convergence Recovery Instant
@@ 1102,34 +1136,44 @@
converging from a prior Convergence Event.
Discussion:
The Convergence Events for a Nested Convergence Event MUST occur with
different neighbors. A possible observation from a Nested
Convergence Event will be the withdrawal of routes from one neighbor
while the routes of another neighbor are being installed.
Measurement Units: N/A
+
Issues: None
See Also: Convergence Event
4. Security Considerations
 Documents of this type do not directly affect the security of
 Internet or corporate networks as long as benchmarking is not
 performed on devices or systems connected to production networks.
 Security threats and how to counter these in SIP and the media layer
 is discussed in RFC3261, RFC3550, and RFC3711 and various other
 drafts. This document attempts to formalize a set of common
 methodology for benchmarking IGP convergence performance in a lab
 environment.
+ Benchmarking activities as described in this memo are limited to
+ technology characterization using controlled stimuli in a laboratory
+ environment, with dedicated address space and the constraints
+ specified in the sections above.
+
+ The benchmarking network topology will be an independent test setup
+ and MUST NOT be connected to devices that may forward the test
+ traffic into a production network, or misroute traffic to the test
+ management network.
+
+ Further, benchmarking is performed on a "blackbox" basis, relying
+ solely on measurements observable external to the DUT/SUT.
+
+ Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
+ benchmarking purposes. Any implications for network security arising
+ from the DUT/SUT SHOULD be identical in the lab and in production
+ networks.
5. IANA Considerations
This document requires no IANA considerations.
6. Acknowledgements
Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
Peter De Vriendt and the BMWG for their contributions to this work.