 1/draftietfbmwgigpdataplaneconvterm17.txt 20090713 20:12:16.000000000 +0200
+++ 2/draftietfbmwgigpdataplaneconvterm18.txt 20090713 20:12:16.000000000 +0200
@@ 1,26 +1,36 @@
 Network Working Group S. Poretsky
 Internet Draft Allot Communications
 Expires: September 08, 2009
 Intended Status: Informational Brent Imhoff
 Juniper Networks

 March 08, 2009
 Terminology for Benchmarking
 LinkState IGP Data Plane Route Convergence
+Network Working Group S. Poretsky
+InternetDraft Allot Communications
+Intended status: Informational B. Imhoff
+Expires: January 14, 2010 Juniper Networks
+ K. Michielsen
+ Cisco Systems
+ July 13, 2009

+Terminology for Benchmarking LinkState IGP Data Plane Route Convergence
+ draftietfbmwgigpdataplaneconvterm18
Status of this Memo
+
This InternetDraft is submitted to IETF in full conformance with the
 provisions of BCP 78 and BCP 79.
+ 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
+ the person(s) controlling the copyright in such materials, this
+ document may not be modified outside the IETF Standards Process, and
+ derivative works of it may not be created outside the IETF Standards
+ Process, except to format it for publication as an RFC or to
+ translate it into languages other than English.
InternetDrafts 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.
InternetDrafts 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 InternetDrafts as reference
material or to cite them other than as "work in progress."
@@ 20,989 +30,1191 @@
other groups may also distribute working documents as Internet
Drafts.
InternetDrafts 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 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 September 8, 2009.
+ This InternetDraft will expire on January 14, 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
and restrictions with respect to this document.
ABSTRACT
 This document describes the terminology for benchmarking Interior
 Gateway Protocol (IGP) Route Convergence. The terminology is to
 be used for benchmarking IGP convergence time through externally
 observable (black box) data plane measurements. The terminology
 can be applied to any linkstate IGP, such as ISIS and OSPF.
+Abstract
 LinkState IGP Data Plane Route Convergence
+ This document describes the terminology for benchmarking Interior
+ Gateway Protocol (IGP) Route Convergence. The terminology is to be
+ used for benchmarking IGP convergence time through externally
+ observable (black box) data plane measurements. The terminology can
+ be applied to any linkstate IGP, such as ISIS and OSPF.
Table of Contents
 1. Introduction and Scope........................................3
 2. Existing Definitions .........................................4
 3. Term Definitions..............................................4
 3.1 States
 3.1.1 Route Convergence....................................4
 3.1.2 Full Convergence.....................................5
 3.1.3 Network Convergence..................................5
 3.1.4 RouteSpecific Convergence...........................6
 3.1.5 Stale Forwarding.....................................6
 3.2 Events
 3.2.1 Convergence Event....................................7
 3.2.2 Convergence Event Trigger............................7
 3.2.3 Convergence Event Instant............................8
 3.2.4 Convergence Recovery Instant.........................8
 3.2.5 First Route Convergence Instant......................9
 3.2.6 Convergence Event Transition.........................9
 3.2.7 Convergence Recovery Transition......................10
 3.2.8 Nested Convergence Events............................10
 3.3 Interfaces
 3.3.1 Local Interface......................................11
 3.3.2 Neighbor Interface...................................11
 3.3.3 Remote Interface.....................................11
 3.3.4 Preferred Egress Interface...........................12
 3.3.5 NextBest Egress Interface...........................12
 3.4 Benchmarking Method
 3.4.1 Packet Loss..........................................13
 3.4.2 Convergence Packet Loss..............................13
 3.4.3 RateDerived Convergence Method......................14
 3.4.4 LossDerived Convergence Method......................14
 3.4.5 Packet Sampling Interval.............................15
 3.5 Benchmarks
 3.5.1 Full Convergence Time................................17
 3.5.2 First Route Convergence Time.........................17
 3.5.3 RouteSpecific Convergence Time......................17
 3.5.4 Sustained Convergence Validation Time................18
 3.5.5 Reversion Convergence Time...........................19
 4. IANA Considerations...........................................19
 5. Security Considerations.......................................19
 6. Acknowledgements..............................................20
 7. References....................................................20
 8. Author's Address..............................................21
 LinkState IGP Data Plane Route Convergence
+
+ 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.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
+ 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 9
+ 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 9
+ 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
+ 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
+ 3.4.4. NextBest Egress Interface . . . . . . . . . . . . . . 10
+ 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.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.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.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23
+ 3.7.6. Sustained Convergence Validation Time . . . . . . . . 23
+ 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24
+ 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24
+ 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 24
+ 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
1. Introduction and Scope
 This draft describes the terminology for benchmarking Interior
 Gateway Protocol (IGP) Route Convergence. The motivation and
 applicability for this benchmarking is provided in [Po07a]. The
 methodology to be used for this benchmarking is described in [Po07m].
+ 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 Convergence Methodology [Po07m].
 These terms apply to IPv4 and IPv6 traffic and IGPs.
+ complete execution of the IGP Route Methodology [Po09m].
 Convergence times are measured at the Tester on the data plane by
+ IGP convergence time is measured on the data plane at the Tester by
observing packet loss through the DUT. The methodology and
 terminology to be used for benchmarking Route Convergence can be
 applied to any linkstate IGP such as ISIS [Ca90] and OSPF [Mo98].
 The data plane is measured to obtain blackbox (externally
 observable) convergence benchmarking metrics. When there is no
 packer loss observed in the data plane, the convergence time
 SHALL be reported as zero.

 An example of Route Convergence as observed and measured from the
 data plane is shown in Figure 1. The graph in Figure 1 shows
 Forwarding Rate versus Time. Time 0 on the Xaxis is on the far
 right of the graph. The Offered Load to the ingress interface of
 the DUT SHOULD equal the measured Throughput [Ba99][Ma98] of the DUT
 and the Forwarding Rate [Ma98] and Convergence Packet Loss is
 measured at the Preferred and NextBest Egress interfaces of the DUT
 befire, during, and after a Convergence Event Trigger. These
 components of the graph are defined in the Term Definitions section.

 Full Convergence> Convergence Convergence
 Recovery Event Event Time=
 Instant Instant Trigger 0sec
 Forwarding Rate= ^ ^ ^ ^ Offered Load=
 Offered Load > \ Packet / <Max Throughput
 \ Loss /<Convergence
 Convergence>\ / Event Transition
 Recovery Transition \ /
 \_____/<Maximum Packet Loss
 ^
 First Route
 Convergence Instant

 Yaxis = Forwarding Rate
 Xaxis = Time (increases right to left to match commercial test
 equipment displays)

 Figure 1. Convergence Graph
 LinkState IGP Data Plane Route Convergence
+ terminology to be used for benchmarking IGP Convergence can be
+ applied to IPv4 and IPv6 traffic and linkstate IGPs such as ISIS
+ [Ca90][Ho08], OSPF [Mo98][Co08], and others.
2. Existing Definitions
 This document uses existing terminology defined in other BMWG
 work. Examples include, but are not limited to:
 Latency [Ref.[Ba91], section 3.8]
 Frame Loss Rate [Ref.[Ba91], section 3.6]
 Throughput [Ref.[Ba91], section 3.17]
+ This document uses existing terminology defined in other BMWG work.
+ Examples include, but are not limited to:
+
+ 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.
3. Term Definitions
 3.1 States
 3.1.1 Route Convergence
+3.1. Convergence Types
+
+3.1.1. Route Convergence
Definition:
 The action to update all components of the router with the
 most recent route change(s) including the Routing
 Information Base (RIB) and Forwarding Information Base (FIB),
 along with software and hardware tables, such that forwarding
 is successful for one or more route entries.
+
+ The process of updating all components of the router, including the
+ Routing Information Base (RIB) and Forwarding Information Base (FIB),
+ along with software and hardware tables, with the most recent route
+ change(s) such that forwarding for a route entry is successful on the
+ NextBest Egress Interface.
Discussion:
 Route Convergence MUST occur after a Convergence Event.
 Route Convergence can be observed externally by the rerouting
 of data traffic to the Nextbest Egress Interface. Also,
 completion of Route Convergence may or may not be sustained
 over time.
+
+ Route Convergence MUST occur after a Convergence Event. Route
+ Convergence can be observed externally by the rerouting of data
+ traffic for a destination matching a route entry to the Nextbest
+ Egress Interface. Completion of Route Convergence may or may not be
+ sustained over time.
Measurement Units: N/A
Issues: None
See Also:
 Network Convergence
 Full Convergence
 Convergence Event
 LinkState IGP Data Plane Route Convergence
 3.1.2 Full Convergence
+ Network Convergence, Full Convergence, Convergence Event
+
+3.1.2. Full Convergence
Definition:
 Route Convergence for an entire FIB in which complete recovery
 from the Convergence Event is indicated by the DUT throughput
 equal to the offered load.
+
+ Route Convergence for all routes in the FIB.
Discussion:
 When benchmarking convergence, it is useful to measure
 the time to converge an entire FIB. For example,
 a Convergence Event can be produced for an OSPF table of
 5000 routes so that the time to converge routes 1 through
 5000 is measured. Completion of Full Convergence is externally
 observable from the data plane when the Throughput of the data
 plane traffic on the NextBest Egress Interface equals the
 offered load.
 Full Convergence MAY be measured using RateDerived Convergence
 Method or calculated using LossDerived Convergence Method.
 Full Convergence may or may not be sustained over time. The
 Sustained Convergence Validation Time MUST be applied.
+ Full Convergence MUST occur after a Convergence Event. Full
+ Convergence can be observed externally by the rerouting of data
+ traffic to destinations matching all route entries to the Nextbest
+ Egress Interface. Completion of Full Convergence is externally
+ observable from the data plane when the Forwarding Rate of the data
+ plane traffic on the NextBest Egress Interface equals the Offered
+ Load.
 Measurement Units: N/A
+ Completion of Full Convergence may or may not be sustained over time.
+ Measurement Units: N/A
Issues: None
See Also:
 Network Convergence
 Route Convergence
 Convergence Event
 3.1.3 Network Convergence
+ Network Convergence, Route Convergence, Convergence Event, Full
+ Convergence Time, Convergence Recovery Instant
+
+3.1.3. Network Convergence
Definition:
 The process of updating of all routing tables, including
 distributed FIBs, in all routers throughout the network.
+
+ Full Convergence in all routers throughout the network.
Discussion:
 Network Convergence requires completion of all Route
 Convergence operations for all routers in the network following
 a Convergence Event. Completion of Network Convergence can be
 observed by recovery of System Under Test (SUT) Throughput to
 equal the offered load, with no Stale Forwarding, and no
 Blenders [Ca01][Ci03].
+
+ Network Convergence includes all Route Convergence operations for all
+ routers in the network following a Convergence Event.
+
+ Completion of Network Convergence can be observed by recovery of the
+ network Forwarding Rate to equal the Offered Load, with no Stale
+ Forwarding, and no Blenders [Ca01][Ci03].
+
+ Completion of Network Convergence may or may not be sustained over
+ time.
Measurement Units: N/A
Issues: None
 LinkState IGP Data Plane Route Convergence
See Also:
 Route Convergence
 Stale Forwarding
 3.1.4 RouteSpecific Convergence
+ Route Convergence, Full Convergence, Stale Forwarding
+
+3.2. Instants
+
+3.2.1. Convergence Event Instant
+
Definition:
 Route Convergence for one or more specific route entries in
 the FIB in which recovery from the Convergence Event is
 indicated when dataplane traffic for the flow [Po06] matching
 that route entry(ies) is routed to the NextBest Egress
 Interface.
+
+ The time instant that a Convergence Event occurs.
Discussion:
 When benchmarking convergence, it is sometimes useful to
 measure the time to converge a single flow [Po06] or group of
 flows to benchmark convergence time for one or a few route
 entries in the FIB instead of the entire FIB. RouteSpecific
 Convergence of a flow is externally observable from the data
 plane when the data plane traffic for that flow is routed to
 the NextBest Egress Interface.
 Measurement Units: N/A
+ 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
+ exhibit packet loss.
+
+ The Tester SHOULD collect a timestamp on the Convergence Event
+ Instant if it is not observable from the data plane.
+
+ Measurement Units:
+
+ hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
+ microseconds.
Issues: None
 See Also:
 Full Convergence
 Route Convergence
 Convergence Event
+ See Also: Convergence Event
+
+3.2.2. Convergence Recovery Instant
 3.1.5 Stale Forwarding
Definition:
 Forwarding of traffic to route entries that no longer exist
 or to route entries with nexthops that are no longer preferred.
+
+ The time instant that Full Convergence has completed.
Discussion:
 Stale Forwarding can be caused by a Convergence Event and can
 manifest as a "blackhole" or microloop that produces packet
 loss. Stale Forwarding can exist until Network Convergence is
 completed. Stale Forwarding cannot be observed with a single
 DUT.
 Measurement Units: N/A
+ 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.
+
+ The Convergence Recovery Instant is observable from the data plane as
+ the instant the DUT forwards traffic to all destinations over the
+ NextBest Egress Interface.
+
+ When using the RateDerived Method, the Convergence Recovery Instant
+ falls within the Packet Sampling Interval preceding the first
+ interval where the observed Forwarding Rate on the NextBest Egress
+ Interface equals the Offered Load.
+
+ Measurement Units:
+
+ hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
+ microseconds.
Issues: None
See Also:
 Network Convergence
 LinkState IGP Data Plane Route Convergence
 3.2 Events
+ Sustained Convergence Validation Time, Full Convergence
 3.2.1 Convergence Event
+3.2.3. First Route Convergence Instant
Definition:
 The occurrence of a planned or unplanned event in the network
 that results in a change in the egress interface of the Device
 Under Test (DUT) for routed packets.
+
+ The time instant the first route entry completes Route Convergence
+ following a Convergence Event
Discussion:
 Convergence Events include link loss, routing protocol session
 loss, router failure, configuration change, and better nexthop
 learned via a routing protocol.
+
+ Any route may be the first to complete Route Convergence. The First
+ Route Convergence Instant is observable from the data plane as the
+ instant that the first packet is received from the NextBest Egress
+ Interface.
Measurement Units:
 N/A
 Issues:
 None
+ hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is
+ microseconds.
 See Also:
 Convergence Packet Loss
 Convergence Event Instant
+ Issues: None
 3.2.2 Convergence Event Trigger
+ See Also: Route Convergence
+
+3.3. Transitions
+
+3.3.1. Convergence Event Transition
Definition:
 An action taken by the Tester to produce a Convergence Event.
+
+ A time interval following a Convergence Event in which Forwarding
+ Rate on the Preferred Egress Interface gradually reduces to zero.
Discussion:
 The Convergence Event Trigger is introduced by the Tester and
 may be indicated by link loss, routing protocol session loss,
 router failure, configuration change, or a better nexthop
 learned via a routing protocol introduced by the Tester.
 Measurement Units:
 N/A
+ The Forwarding Rate during a Convergence Event Transition may not
+ decrease linearly.
 Issues:
 None
+ The Forwarding Rate observed on all DUT egress interfaces may or may
+ not decrease to zero.
+
+ The Offered Load, the number of routes, and the Packet Sampling
+ Interval influence the observations of the Convergence Event
+ Transition using the RateDerived Method. This is further discussed
+ with the term "RateDerived Method".
+
+ Measurement Units: seconds
+
+ Issues: None
See Also:
 Convergence Event
 Convergence Packet Loss
 Convergence Recovery Instant
 LinkState IGP Data Plane Route Convergence
 3.2.3 Convergence Event Instant
+ Convergence Event, RateDerived Method
+
+3.3.2. Convergence Recovery Transition
Definition:
 The time instant that a Convergence Event becomes observable in
 the data plane.
+
+ A time interval following the First Route Convergence Instant in
+ which Forwarding Rate on the NextBest Egress Interface gradually
+ increases to equal the Offered Load.
Discussion:
 Convergence Event Instant is observable from the data
 plane as the precise time that the device under test begins
 to exhibit packet loss. The Convergence Event Instant is
 produced by the Convergence Event Trigger. The Convergence
 Event Instant always occurs concurrent or subsequent to the
 Tester introducing the Convergence Event Trigger.
 Measurement Units:
 hh:mm:ss:nnn:uuu,
 where 'nnn' is milliseconds and 'uuu' is microseconds.
+ The Forwarding Rate observed during a Convergence Recovery Transition
+ may not increase linearly.
+
+ The Offered Load, the number of routes, and the Packet Sampling
+ Interval influence the observations of the Convergence Recovery
+ Transition using the RateDerived Method. This is further discussed
+ with the term "RateDerived Method".
+
+ Measurement Units: seconds
Issues: None
See Also:
 Convergence Event
 Convergence Packet Loss
 Convergence Recovery Instant
 3.2.4 Convergence Recovery Instant
+ Full Convergence,First Route Convergence Instant, RateDerived Method
+
+3.4. Interfaces
+
+3.4.1. Local Interface
Definition:
 The time instant that Full Convergence completion is
 observed.
+
+ An interface on the DUT.
Discussion:
 Convergence Recovery Instant is measurable from the data
 plane as the precise time that the device under test completes
 Full Convergence. The Convergence Recovery Instant MUST be
 maintained for an interval of duration equal to the Sustained
 Convergence Validation Time.
 Measurement Units:
 hh:mm:ss:nnn:uuu,
 where 'nnn' is milliseconds and 'uuu' is microseconds.
+ A failure of the Local Interface indicates that the failure occurred
+ directly on the DUT.
 Issues:
 None
+ Measurement Units: N/A
 See Also:
 Sustained Convergence Validation Time
 Convergence Packet Loss
 Convergence Event Instant
 LinkState IGP Data Plane Route Convergence
+ Issues: None
+
+ See Also: Remote Interface
+
+3.4.2. Remote Interface
 3.2.5 First Route Convergence Instant
Definition:
 The time instant a first route entry has converged
 following a Convergence Event, as observed by receipt of
 the first packet from the NextBest Egress Interface.
+
+ An interface on a neighboring router that is not directly connected
+ to any interface on the DUT.
Discussion:
 The First Route Convergence Instant is an indication that the
 process to achieve Full Convergence has begun. Any route may
 be the first to converge for First Route Convergence Instant.
 Measurement on the dataplane enables the First Route
 Convergence Instant to be observed without any whitebox
 information from the DUT.
 Measurement Units:
 hh:mm:ss:nnn:uuu,
 where 'nnn' is milliseconds and 'uuu' is microseconds.
+ A failure of a Remote Interface indicates that the failure occurred
+ on a neighbor router's interface that is not directly connected to
+ the DUT.
 Issues:
 None
+ Measurement Units: N/A
 See Also:
 Route Convergence
 Full Convergence
 Stale Forwarding
+ Issues: None
+
+ See Also: Local Interface
+
+3.4.3. Preferred Egress Interface
 3.2.6 Convergence Event Transition
Definition:
 A time interval observed following a Convergence Event in which
 Throughput gradually reduces to a minimum value.
+
+ The outbound interface from the DUT for traffic routed to the
+ preferred nexthop.
Discussion:
 The Convergence Event Transition is best observed for Full
 Convergence. The egress packet rate observed during a
 Convergence Event Transition may not decrease linearly and may
 not decrease to zero. Both the offered load and the Packet
 Sampling Interval influence the observations of the Convergence
 Event Transition. For example, it is possible that if the
 Convergence Event were to cause the Throughput [Ba91] to drop
 to zero then this may not be observed if the Packet Sampling
 Interval is set too high. This is further discussed with the
 term "Packet Sampling Interval".
 Measurement Units:
 seconds
+ The Preferred Egress Interface is the egress interface prior to a
+ Convergence Event.
+
+ Measurement Units: N/A
Issues: None
 LinkState IGP Data Plane Route Convergence
 See Also:
 Convergence Event
 Full Convergence
 Packet Sampling Interval
+ See Also: NextBest Egress Interface
 3.2.7 Convergence Recovery Transition
+3.4.4. NextBest Egress Interface
Definition:
 The characteristic of the DUT in which Throughput gradually
 increases to equal the offered load.
+
+ The outbound interface from the DUT for traffic routed to the second
+ best nexthop.
Discussion:
 The Convergence Recovery Transition is best observed for
 Full Convergence. The egress packet rate observed during
 a Convergence Recovery Transition may not increase linearly.
 Both the offered load and the Packet Sampling Interval
 influence the observations of the Convergence Recovery
 Transition. This is further discussed with the term
 "Packet Sampling Interval".
 Measurement Units:
 seconds
+ The NextBest Egress Interface becomes the egress interface after a
+ Convergence Event.
+
+ The NextBest Egress Interface is of the same media type and link
+ speed as the Preferred Egress Interface.
+
+ Measurement Units: N/A
Issues: None
 See Also:
 Full Convergence
 Packet Sampling Interval
+ See Also: Preferred Egress Interface
 3.2.8 Nested Convergence Events
+3.5. Benchmarking Methods
+
+3.5.1. RateDerived Method
Definition:
 The occurrence of a Convergence Event while the route
 table is converging from a prior Convergence Event.
+
+ The method to calculate convergence time benchmarks from observing
+ Forwarding Rate each Packet Sampling Interval.
Discussion:
 The Convergence Events for a Nested Convergence Event
 MUST occur with different neighbors. A common
 observation from a Nested Convergence Event will be
 the withdrawal of routes from one neighbor while the
 routes of another neighbor are being installed.
+
+ 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 ^
+  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
+ 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
See Also:
 Convergence Event
 LinkState IGP Data Plane Route Convergence
 3.3 Interfaces
+ Packet Sampling Interval, Convergence Event, Convergence Event
+ Instant, Full Convergence
 3.3.1 Local Interface
+3.5.2. LossDerived Method
Definition:
 An interface on the DUT.
+
+ The method to calculate the LossDerived Convergence Time and Loss
+ Derived Loss of Connectivity Period benchmarks from the amount of
+ packet loss.
Discussion:
 A failure of the Local Interface indicates that the failure
 occurred directly on the DUT.
 Measurement Units: N/A
+ The Offered Load SHOULD consists 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.
+
+ 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).
+
+ 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
+ Convergence Event, such as routes via nonimpacted members of ECMP or
+ parallel links.
+
+ Measurement Units: seconds
Issues: None
See Also:
 Neighbor Interface
 Remote Interface
 3.3.2 Neighbor Interface
+ LossDerived Convergence Time, LossDerived Loss of Connectivity
+ Period, Convergence Packet Loss
+
+3.5.3. RouteSpecific LossDerived Method
Definition:
 The interface on the neighbor router or tester that is
 directly linked to the DUT's Local Interface.
+
+ The method to calculate the RouteSpecific Convergence Time benchmark
+ from the amount of packet loss during convergence for a specific
+ route entry.
Discussion:
 A failure of a Neighbor Interface indicates that a
 failure occurred on a neighbor router's interface that
 directly links the neighbor router to the DUT.
 Measurement Units: N/A
+ 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.
+
+ 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).
+
+ 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
See Also:
 Local Interface
 Remote Interface
 3.3.3 Remote Interface
+ RouteSpecific Convergence Time, Route Loss of Connectivity Period,
+ Convergence Packet Loss
+
+3.6. Benchmarks
+
+3.6.1. Full Convergence Time
Definition:
 An interface on a neighboring router that is not directly
 connected to any interface on the DUT.
+
+ The time duration of the period between the Convergence Event Instant
+ and the Convergence Recovery Instant as observed using the Rate
+ Derived Method.
Discussion:
 A failure of a Remote Interface indicates that the failure
 occurred on a neighbor router's interface that is not
 directly connected to the DUT.
 LinkState IGP Data Plane Route Convergence
+ Using the RateDerived Method, Full Convergence Time can be
+ calculated as the time difference between the Convergence Event
+ Instant and the Convergence Recovery Instant, as shown in Equation 1.
 Measurement Units:
 N/A
+ Full Convergence Time =
+ Convergence Recovery Instant  Convergence Event Instant
 Issues:
 None
+ Equation 1
+
+ The Convergence Event Instant can be derived from the Forwarding Rate
+ observation or from a timestamp collected by the Tester.
+
+ For the testcases described in [Po09m], it is expected that Full
+ Convergence Time equals the maximum RouteSpecific Convergence Time
+ when benchmarking all routes in FIB using the RouteSpecific Loss
+ Derived Method.
+
+ It is not possible to measure Full Convergence Time using the Loss
+ Derived Method.
+
+ Measurement Units: seconds
+
+ Issues: None
See Also:
 Local Interface
 Neighbor Interface
 3.3.4 Preferred Egress Interface
+ Full Convergence, RateDerived Method, RouteSpecific LossDerived
+ Method
+
+3.6.2. First Route Convergence Time
Definition:
 The outbound interface from the DUT for traffic routed to the
 preferred nexthop.
+
+ The duration of the period between the Convergence Event Instant and
+ the First Route Convergence Instant as observed using the Rate
+ Derived Method.
Discussion:
 The Preferred Egress Interface is the egress interface prior
 to a Convergence Event.
 Measurement Units:
 N/A
+ Using the RateDerived Method, First Route Convergence Time can be
+ calculated as the time difference between the Convergence Event
+ Instant and the First Route Convergence Instant, as shown with
+ Equation 2.
 Issues:
 None
+ First Route Convergence Time =
+ First Route Convergence Instant  Convergence Event Instant
+
+ Equation 2
+
+ The Convergence Event Instant can be derived from the Forwarding Rate
+ observation or from a timestamp collected by the Tester.
+
+ For the testcases described in [Po09m], it is expected that First
+ Route Convergence Time equals the minimum RouteSpecific Convergence
+ Time when benchmarking all routes in FIB using the RouteSpecific
+ LossDerived Method.
+
+ It is not possible to measure First Route Convergence Time using the
+ LossDerived Method.
+
+ Measurement Units: seconds
+
+ Issues: None
See Also:
 NextBest Egress Interface
 3.3.5 NextBest Egress Interface
+ RateDerived Method, RouteSpecific LossDerived Method, First Route
+ Convergence Instant
+
+3.6.3. RouteSpecific Convergence Time
Definition:
 The outbound interface from the DUT for traffic routed to the
 secondbest nexthop. It is the same media type and link speed
 as the Preferred Egress Interface
+
+ The amount of time it takes for Route Convergence to be completed for
+ a specific route, as calculated from the amount of packet loss during
+ convergence for a single route entry.
Discussion:
 The NextBest Egress Interface becomes the egress interface
 after a Convergence Event.
 Measurement Units:
 N/A
+ RouteSpecific Convergence Time can only be measured using the Route
+ Specific LossDerived Method.
+
+ If the applied Convergence Event causes instantaneous traffic loss
+ for all routes at the Convergence Event Instant, Connectivity Packet
+ Loss should be observed. Connectivity Packet Loss is the combined
+ packet loss observed on Preferred Egress Interface and NextBest
+ Egress Interface. When benchmarking RouteSpecific Convergence Time,
+ Connectivity Packet Loss is measured and Equation 3 is applied for
+ 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.
+
+ RouteSpecific Convergence Time =
+ Convergence Packet Loss for specific route/Offered Load per route
+  (Convergence Event Instant  start traffic instant)
+
+ Equation 4
+
+ The Convergence Event Instant and start traffic 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].
+
+ Measurement Units: seconds
Issues: None
See Also:
 Preferred Egress Interface
 LinkState IGP Data Plane Route Convergence
 3.4 Benchmarking Methods
 3.4.1 Packet Loss
+ Convergence Event, Convergence Packet Loss, Connectivity Packet Loss,
+ Route Convergence
+
+3.6.4. LossDerived Convergence Time
Definition:
 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.
+
+ The average Route Convergence time for all routes in FIB, as
+ calculated from the amount of packet loss during convergence.
Discussion:
 Packet Loss is a modified version of the term "Frame Loss Rate"
 as defined in [Ba91]. The term "Frame Loss" is intended for
 Ethernet Frames while "Packet Loss" is intended for IP packets.
 Packet Loss can be measured as a reduction in forwarded traffic
 from the Throughput [Ba91] of the DUT.
 Measurement units:
 Number of offered packets that are not forwarded.
+ LossDerived Convergence Time is measured using the LossDerived
+ Method.
+
+ If the applied Convergence Event causes instantaneous traffic loss
+ for all routes at the Convergence Event Instant, Connectivity Packet
+ Loss should be observed. Connectivity Packet Loss is the combined
+ packet loss observed on Preferred Egress Interface and NextBest
+ 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.
+
+ LossDerived Convergence Time =
+ Convergence Packet Loss/Offered Load
+  (Convergence Event Instant  start traffic instant)
+
+ Equation 6
+
+ The Convergence Event Instant and start traffic instant SHOULD be
+ collected by the Tester.
+
+ Measurement Units: seconds
Issues: None
See Also:
 Convergence Packet Loss
 3.4.2 Convergence Packet Loss
+ Convergence Packet Loss, Connectivity Packet Loss, Route Convergence
+
+3.6.5. Route Loss of Connectivity Period
Definition:
 The number of packets lost due to a Convergence Event
 until Full Convergence completes.
+
+ The time duration of traffic loss for a specific route entry
+ following a Convergence Event until Full Convergence completion, as
+ observed using the RouteSpecific LossDerived Method.
Discussion:
 Convergence Packet Loss includes packets that were lost and
 packets that were delayed due to buffering. The Convergence
 Packet Loss observed in a Packet Sampling Interval may or may
 not be equal to the number of packets in the offered load
 during the interval following a Convergence Event (see Figure
 1).
 Measurement Units:
 number of packets
+ 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
+ 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.
+
+ Route Loss of Connectivity Period =
+ Connectivity Packet Loss for specific route/Offered Load per route
+
+ Equation 7
+
+ Route Loss of Connectivity Period SHOULD be measured using Route
+ Specific LossDerived Method.
+
+ Measurement Units: seconds
Issues: None
See Also:
 Packet Loss
 Route Convergence
 Convergence Event
 Packet Sampling Interval
 LinkState IGP Data Plane Route Convergence
 3.4.3 RateDerived Convergence Method
 Definition:
 The method to calculate convergence time benchmarks from the
 amount of time that Convergence Packet Loss persists upon
 occurrence of a Convergence Event.
+ RouteSpecific Convergence Time, RouteSpecific LossDerived Method,
+ Connectivity Packet Loss
 RateDerived Convergence Method can be calculated as the time
 difference from the Convergence Event Instant to the
 Convergence Recovery Instant, as shown with Equation 1.
+3.6.6. LossDerived Loss of Connectivity Period
 (Equation 1)
 RateDerived Convergence Method =
 Convergence Recovery Instant  Convergence Event Instant.
+ Definition:
+
+ The average time duration of traffic loss for all routes following a
+ Convergence Event until Full Convergence completion, as observed
+ using the LossDerived Method.
Discussion:
 It is RECOMMENDED that the RateDerived Convergence Method be
 measured when benchmarking convergence times. The RateDerived
 Convergence Method SHOULD be measured with an Offered Load at
 the Throughput of the DUT. At least one packet per route
 in the FIB for all routes in the FIB MUST be offered to the DUT
 within the Packet Sampling Interval.
 It is possible to measure no packet loss, which results in a
 RateDerived Convergence Time benchmark of zero. Failure to
 achieve Full Convergence results in a RateDerived Convergence
 Time benchmark of infinity.
+ In general the LossDerived Loss of Connectivity Period is not equal
+ to the LossDerived Convergence Time. If the DUT continues to
+ forward traffic to the Preferred Egress Interface after the
+ Convergence Event is applied then the LossDerived Loss of
+ Connectivity Period will be smaller than the LossDerived Convergence
+ Time. This is also specifically the case after reversing a failure
+ event.
 Measurement Units:
 seconds
+ The LossDerived Loss of Connectivity Period may be equal to the
+ LossDerived 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] each route's Route Loss of
+ Connectivity Period is expected to be a single Loss Period [Ko02].
+
+ When benchmarking LossDerived Loss of Connectivity Period,
+ Connectivity Packet Loss is measured for all routes and Equation 8 is
+ applied. The calculation is equal to Equation 5 in Section 3.6.4.
+
+ LossDerived Loss of Connectivity Period =
+ Connectivity Packet Loss for all routes/Offered Load
+
+ Equation 8
+
+ LossDerived Loss of Connectivity Period SHOULD be measured using
+ LossDerived Method.
+
+ Measurement Units: seconds
Issues: None
See Also:
 Convergence Packet Loss
 Convergence Recovery Instant
 Convergence Event Instant
 Full Convergence
 3.4.4 LossDerived Convergence Method
+ LossDerived Convergence Time, LossDerived Method, Connectivity
+ Packet Loss
+
+3.7. Measurement Terms
+
+3.7.1. Convergence Event
+
Definition:
 The method to calculate convergence time benchmarks from the
 amount of Convergence Packet Loss. LossDerived Convergence
 Method can be calculated from Convergence Packet Loss as shown
 with Equation 2.
 Equation 2 
 LossDerived Convergence Method =
 Convergence Packets Loss / Offered Load
 where units are packets / packets/second = seconds
 LinkState IGP Data Plane Route Convergence
+ The occurrence of a planned or unplanned event in the network that
+ will result in a change in the egress interface of the Device Under
+ Test (DUT) for routed packets.
Discussion:
 Ideally, the Convergence Event Transition and Convergence
 Recovery Transition are instantaneous so that the RateDerived
 Convergence Method = LossDerived Convergence Method. However,
 router implementations are less than ideal. LossDerived
 Convergence Method gives a better than actual result when
 converging many routes simultaneously because it ignores the
 transitions. The RateDerived Convergence Method takes the
 transitions into account.
 Equation 2 calculates the average convergence time over all
 routes to which packets have been sent. The average convergence
 time is often lower than the maximum convergence time
 over all routes, so it can produce a result that is faster than
 the actual convergence time.. Therefore, LossDerived
 Convergence Method is not the preferred method to measure
 convergence benchmarks. For these reasons the RECOMMENDED
 method to obtain a benchmark metric for convergence time is the
 RateDerived Convergence Method.
+ Convergence Events include but are not limited to link loss, routing
+ protocol session loss, router failure, configuration change, and
+ better nexthop learned via a routing protocol.
 Measurement Units:
 seconds
+ Measurement Units: N/A
Issues: None
 See Also:
 Convergence Packet Loss
 RateDerived Convergence Method
 RouteSpecific Convergence
 Convergence Event Transition
 Convergence Recovery Transition
+ See Also: Convergence Event Instant
+
+3.7.2. Packet Loss
 3.4.5 Packet Sampling Interval
Definition:
 The interval at which the tester (test equipment) polls to make
 measurements for arriving packet flows.
+
+ 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:
 At least one packet per route in the FIB for all routes in the
 FIB MUST be offered to the DUT within the Packet Sampling
 Interval. Metrics measured at the Packet Sampling Interval
 MUST include Forwarding Rate and Convergence Packet Loss.
 Packet Sampling Interval can influence the Convergence Graph.
 This is particularly true when implementations complete Full
 Convergence in less time than the Packet Sampling Interval. The
 Convergence Event Transition and Convergence Recovery Transition
 LinkState IGP Data Plane Route Convergence
+ 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.
 can become exaggerated when the Packet Sampling Interval is too
 long. In this condition, the RateDerived Convergence Method
 may produce a larger than actual convergence time. In such
 cases the LossDerived Convergence Method may produce a more
 accurate result. The recommended value for configuration of
 the Packet Sampling Interval is provided in [Po07m].
+ Measurement units:
 Measurement Units: seconds
+ Number of offered packets that are not forwarded.
Issues: None
 See Also:
 Convergence Packet Loss
 Convergence Event Transition
 Convergence Recovery Transition

3.5 Benchmarks
+ See Also: Convergence Packet Loss
 3.5.1 Full Convergence Time
+3.7.3. Convergence Packet Loss
Definition:
 The amount of time it takes for Full Convergence to occur.
+
+ The number of packets lost due to a Convergence Event until Full
+ Convergence completes, as observed on the NextBest Egress Interface.
Discussion:
 Full Convergence Time can be determined using the RateDerived
 Convergence Method or LossDerived Convergence Method. The
 RateDerived Convergence Method is RECOMMENDED. When
 measuring RouteSpecific Convergence Time, there may be
 conditions in which the maximum Route Specific Convergence Time
 can be reported as the Full Convergence Time. Full Convergence
 may or may not be sustained over time. The Sustained
 Convergence Validation Time MUST be applied.
 Measurement Units:
 seconds
+ Convergence Packet Loss is observed on the NextBest Egress
+ Interface. It only needs to be observed for Convergence Events that
+ do not cause instantaneous traffic loss at Convergence Event Instant.
+
+ Convergence Packet Loss includes packets that were lost and packets
+ that were delayed due to buffering. The magnitude of an acceptable
+ Forwarding Delay is a parameter of the methodology. If a maximum
+ acceptable Forwarding Delay threshold is applied it MUST be reported.
+
+ Measurement Units: number of packets
Issues: None
See Also:
 Full Convergence
 RateDerived Convergence Method
 LossDerived Convergence Method
 3.5.2 First Route Convergence Time
+ Packet Loss, Full Convergence, Convergence Event, Connectivity Packet
+ Loss
+
+3.7.4. Connectivity Packet Loss
Definition:
 The amount of time for Convergence Packet Loss until the
 convergence of a first route entry on the NextBest Egress
 Interface, as indicated by the First Route Convergence
 Instant.
 LinkState IGP Data Plane Route Convergence
+ The number of packets lost due to a Convergence Event until Full
+ Convergence completes.
Discussion:
 The First Route Convergence Time benchmarking metric can be
 measured when benchmarking either Full Convergence or
 RouteSpecific Convergence. When benchmarking Full Convergence,
 First Route Convergence Time can be measured as the time
 difference from the Convergence Event Instant and the First
 Route Convergence Instant, as shown with Equation 4a.
 (Equation 4a)
 First Route Convergence Time =
 First Route Convergence Instant  Convergence Event Instant
+ Connectivity Packet Loss is observed on all DUT egress interfaces.
 First Route Convergence Time should be measured at the maximum
 Throughput of the DUT. At least one packet per route in the FIB
 for all routes in the FIB MUST be offered to the DUT within the
 Packet Sampling Interval. Failure to achieve the First Route
 Convergence Instant results in a First Route Convergence Time
 benchmark of infinity.
+ Convergence Packet Loss includes packets that were lost and packets
+ that were delayed due to buffering. The magnitude of an acceptable
+ Forwarding Delay is a parameter of the methodology. If a maximum
+ acceptable Forwarding Delay threshold is applied it MUST be reported.
 Measurement Units:
 seconds
+ Measurement Units: number of packets
Issues: None
See Also:
+
+ Packet Loss, Route Loss of Connectivity Period, Convergence Event,
Convergence Packet Loss
 First Route Convergence Instant
 3.5.3 RouteSpecific Convergence Time
+3.7.5. Packet Sampling Interval
Definition:
 The amount of time it takes for RouteSpecific Convergence to
 be completed as calculated from the amount of Convergence
 Packet Loss for the flow associated to a specific route.

 RouteSpecific Convergence Time can be calculated from
 Convergence Packet Loss as shown with Equation 3.
 (Equation 3) RouteSpecific Convergence Time =
 Convergence Packets Loss / Offered Load
 where units are packets / packets/second = seconds
 LinkState IGP Data Plane Route Convergence
+ The interval at which the Tester (test equipment) polls to make
+ measurements for arriving packets.
Discussion:
 It is possible to provide an offered load that has flows
 matching every route entry in the FIB and benchmarking
 RouteSpecific Convergence Time for all route entries. The
 number of flows that can be measured is dependent upon the flow
 measurement capabilities of the Tester. When benchmarking
 RouteSpecific Convergence, Convergence Packet Loss is measured
 for specific flow(s) and Equation 3 is applied for each flow.
 Each flow has a single destination address matching a different
 route entry. The fastest measurable convergence time is equal
 to the time between two consecutive packets of a flow offered
 by the Tester. In practice, the fastest measurable
 convergence time is the Packet Sampling Interval of 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 [Po07m].
+ 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.
 Measurement Units:
 seconds
+ 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.
 Issues:
 None
+ 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
+ Interval does not contribute to the measurement accuracy.
 See Also:
 Convergence Event
 Convergence Packet Loss
 RouteSpecific Convergence
+ Measurement Units: seconds
+
+ Issues: None
+
+ See Also: RateDerived Method
+
+3.7.6. Sustained Convergence Validation Time
 3.5.4 Sustained Convergence Validation Time
Definition:
 The amount of time for which the completion of Full
 Convergence is maintained without additional packet loss.
+
+ 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 Throughput 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 [Ba99] which recommends waiting 2 seconds
 for residual frames to arrive and 5 seconds for DUT
 restabilization.
 LinkState IGP Data Plane Route Convergence
+ 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
+ 5 seconds for DUT restabilization.
 Measurement Units:
 seconds
+ Measurement Units: seconds
Issues: None
See Also:
 Full Convergence
 Convergence Recovery Instant
 3.5.5 Reversion Convergence Time
+ Full Convergence, Convergence Recovery Instant
+
+3.8. Miscellaneous Terms
+
+3.8.1. Stale Forwarding
Definition:
 The amount of time for the DUT to complete Full Convergence
 to the Preferred Egress Interface, instead of the NextBest
 Egress Interface, upon recovery from a Convergence Event.
+
+ Forwarding of traffic to route entries that no longer exist or to
+ route entries with nexthops that are no longer preferred.
Discussion:
 Reversion Convergence Time is the amount of time for Full
 Convergence to the original egress interface. This is
 achieved by recovering from the Convergence Event, such as
 restoring the failed link. Reversion Convergence Time
 can be measured using the RateDerived Convergence Method
 or LossDerived Convergence Method. The RateDerived
 Convergence Method is RECOMMENDED. It is possible to have
 the Reversion Convergence Time differ from the Full
 Convergence Time.
 Measurement Units: seconds
+ Stale Forwarding can be caused by a Convergence Event and can
+ manifest as a "blackhole" or microloop that produces packet loss, or
+ outoforder packets, or delayed packets. Stale Forwarding can exist
+ until Network Convergence is completed.
+
+ Measurement Units: N/A
Issues: None
 See Also:
 Preferred Egress Interface
 Convergence Event
 RateDerived Convergence Method
+ See Also: Network Convergence
4. IANA Considerations
+3.8.2. Nested Convergence Event
 This document requires no IANA considerations.
+ Definition:
5. Security Considerations
+ The occurrence of a Convergence Event while the route table is
+ 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 terminology for benchmarking IGP convergence performance
 in a lab environment.
+ 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.
 LinkState IGP Data Plane Route Convergence
+5. IANA Considerations
+
+ This document requires no IANA considerations.
6. Acknowledgements
+
Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,
 Kris Michielsen and the BMWG for their contributions to this work.
+ Peter De Vriendt and the BMWG for their contributions to this work.
7. References
 7.1 Normative References
 [Ba91] Bradner, S. "Benchmarking Terminology for Network
 Interconnection Devices", RFC1242, July 1991.
 [Ba99] Bradner, S. and McQuaid, J., "Benchmarking
 Methodology for Network Interconnect Devices",
 RFC 2544, March 1999.
+7.1. Normative References
+
+ [Br91] Bradner, S., "Benchmarking terminology for network
+ interconnection devices", RFC 1242, July 1991.
[Br97] Bradner, S., "Key words for use in RFCs to Indicate
 [Ca90] Callon, R., "Use of OSI ISIS for Routing in TCP/IP and Dual
 Environments", RFC 1195, December 1990.
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
 [Ma98] Mandeville, R., "Benchmarking Terminology for LAN
 Switching Devices", RFC 2285, February 1998.
+ [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
+ Network Interconnect Devices", RFC 2544, March 1999.
 [Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.
+ [Ca90] Callon, R., "Use of OSI ISIS for routing in TCP/IP and dual
+ environments", RFC 1195, December 1990.
 [Mo06] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
 November 2006.
+ [Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
+ IPv6", RFC 5340, July 2008.
 [Po06] Poretsky, S., et al., "Terminology for Benchmarking
 Networklayer Traffic Control Mechanisms", RFC 4689,
+ [Ho08] Hopps, C., "Routing IPv6 with ISIS", RFC 5308,
+ October 2008.
+
+ [Ko02] Koodli, R. and R. Ravikanth, "Oneway Loss Pattern Sample
+ Metrics", RFC 3357, August 2002.
+
+ [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
+ Devices", RFC 2285, February 1998.
+
+ [Mo06] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
+ and J. Perser, "Packet Reordering Metrics", RFC 4737,
November 2006.
 [Po07a] Poretsky, S., "Benchmarking Applicability for LinkState
+ [Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+ [Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
+ "Terminology for Benchmarking Networklayer Traffic Control
+ Mechanisms", RFC 4689, October 2006.
+
+ [Po09a] Poretsky, S., "Considerations for Benchmarking LinkState
IGP Data Plane Route Convergence",
 draftietfbmwgigpdataplaneconvapp17, work in progress,
 March 2009.
+ draftietfbmwgigpdataplaneconvapp17 (work in
+ progress), March 2009.
 [Po07m] Poretsky, S. and Imhoff, B., "Benchmarking Methodology for
+ [Po09m] Poretsky, S. and B. Imhoff, "Benchmarking Methodology for
LinkState IGP Data Plane Route Convergence",
 draftietfbmwgigpdataplaneconvmeth17, work in progress,
 March 2009.
+ draftietfbmwgigpdataplaneconvmeth18 (work in
+ progress), July 2009.
 7.2 Informative References
 [Ca01] S. Casner, C. Alaettinoglu, and C. Kuan, "A FineGrained View
 of High Performance Networking", NANOG 22, June 2001.
+7.2. Informative References
 [Ci03] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized
 Active Measurements on a Tier 1 IP Backbone", IEEE
 Communications Magazine, pp9097, May 2003.
+ [Ca01] Casner, S., Alaettinoglu, C., and C. Kuan, "A FineGrained
+ View of High Performance Networking", NANOG 22, June 2001.
 LinkState IGP Data Plane Route Convergence
+ [Ci03] Ciavattone, L., Morton, A., and G. Ramachandran,
+ "Standardized Active Measurements on a Tier 1 IP Backbone",
+ IEEE Communications Magazine p9097, May 2003.
8. Author's Address
+Authors' Addresses
Scott Poretsky
Allot Communications
67 South Bedford Street, Suite 400
Burlington, MA 01803
USA
+
Phone: + 1 508 309 2179
Email: sporetsky@allot.com
Brent Imhoff
Juniper Networks
1194 North Mathilda Ave
Sunnyvale, CA 94089
USA
+
Phone: + 1 314 378 2571
 EMail: bimhoff@planetspork.com
+ Email: bimhoff@planetspork.com
+
+ Kris Michielsen
+ Cisco Systems
+ 6A De Kleetlaan
+ Diegem, BRABANT 1831
+ Belgium
+
+ Email: kmichiel@cisco.com