draft-ietf-bmwg-igp-dataplane-conv-term-20.txt   draft-ietf-bmwg-igp-dataplane-conv-term-21.txt 
Network Working Group S. Poretsky Network Working Group S. Poretsky
Internet-Draft Allot Communications Internet-Draft Allot Communications
Intended status: Informational B. Imhoff Intended status: Informational B. Imhoff
Expires: September 9, 2010 Juniper Networks Expires: November 11, 2010 Juniper Networks
K. Michielsen K. Michielsen
Cisco Systems Cisco Systems
March 8, 2010 May 10, 2010
Terminology for Benchmarking Link-State IGP Data Plane Route Convergence Terminology for Benchmarking Link-State IGP Data Plane Route Convergence
draft-ietf-bmwg-igp-dataplane-conv-term-20 draft-ietf-bmwg-igp-dataplane-conv-term-21
Abstract Abstract
This document describes the terminology for benchmarking Interior This document describes the terminology for benchmarking Interior
Gateway Protocol (IGP) Route Convergence. The terminology is to be Gateway Protocol (IGP) Route Convergence. The terminology is to be
used for benchmarking IGP convergence time through externally used for benchmarking IGP convergence time through externally
observable (black box) data plane measurements. The terminology can observable (black box) data plane measurements. The terminology can
be applied to any link-state IGP, such as ISIS and OSPF. be applied to any link-state IGP, such as ISIS and OSPF.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on November 11, 2010.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 5 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 5 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 6 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 6 3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 6 3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 7 3.1.3. Network Convergence . . . . . . . . . . . . . . . . . 6
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 7 3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 8 3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 7
3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 8 3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
3.2.4. First Route Convergence Instant . . . . . . . . . . . 9 3.2.4. First Route Convergence Instant . . . . . . . . . . . 8
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 9 3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 10 3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 11 3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 11 3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 11 3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 12 3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 11
3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 12 3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 12 3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11
3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 14 3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 14
3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 16 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 15
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 17 3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 16
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 17 3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 16
3.6.2. First Route Convergence Time . . . . . . . . . . . . . 17 3.6.2. First Route Convergence Time . . . . . . . . . . . . . 17
3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 18 3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 18
3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 20 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 19
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 21 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 20
3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 22 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 21
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 23 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 22
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 23 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 22
3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 23 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 22
3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 23 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 23
3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 24 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 23
3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 25 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 24
3.7.6. Sustained Convergence Validation Time . . . . . . . . 25 3.7.6. Sustained Convergence Validation Time . . . . . . . . 25
3.7.7. Forwarding Delay Threshold . . . . . . . . . . . . . . 26 3.7.7. Forwarding Delay Threshold . . . . . . . . . . . . . . 25
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26
3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 26 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 26
3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 27 3.8.2. Nested Convergence Event . . . . . . . . . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 27 4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28 7.1. Normative References . . . . . . . . . . . . . . . . . . . 27
7.2. Informative References . . . . . . . . . . . . . . . . . . 29 7.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction and Scope 1. Introduction and Scope
This draft describes the terminology for benchmarking Link-State This draft describes the terminology for benchmarking Link-State
Interior Gateway Protocol (IGP) Convergence. The motivation and Interior Gateway Protocol (IGP) Convergence. The motivation and
applicability for this benchmarking is provided in [Po09a]. The applicability for this benchmarking is provided in [Po09a]. The
methodology to be used for this benchmarking is described in [Po09m]. methodology to be used for this benchmarking is described in [Po10m].
The purpose of this document is to introduce new terms required to The purpose of this document is to introduce new terms required to
complete execution of the IGP Route Methodology [Po09m]. complete execution of the IGP Route Methodology [Po10m].
IGP convergence time is measured on the data plane at the Tester by IGP convergence time is measured on the data plane at the Tester by
observing packet loss through the DUT. The methodology and observing packet loss through the DUT. The methodology and
terminology to be used for benchmarking IGP Convergence can be terminology to be used for benchmarking IGP Convergence can be
applied to IPv4 and IPv6 traffic and link-state IGPs such as ISIS applied to IPv4 and IPv6 traffic and link-state IGPs such as ISIS
[Ca90][Ho08], OSPF [Mo98][Co08], and others. [Ca90][Ho08], OSPF [Mo98][Co08], and others.
2. Existing Definitions 2. Existing Definitions
This document uses existing terminology defined in other BMWG work. This document uses existing terminology defined in other BMWG work.
Examples include, but are not limited to: Examples include, but are not limited to:
Frame Loss Rate [Ref.[Br91], section 3.6] Frame Loss Rate [Ref.[Br91], section 3.6]
Throughput [Ref.[Br91], section 3.17] Throughput [Ref.[Br91], section 3.17]
Offered Load [Ref.[Ma98], section 3.5.2] Offered Load [Ref.[Ma98], section 3.5.2]
Forwarding Rate [Ref.[Ma98], section 3.6.1] Forwarding Rate [Ref.[Ma98], section 3.6.1]
Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] Device Under Test (DUT) [Ref.[Ma98], section 3.1.1]
System Under Test (SUT) [Ref.[Ma98], section 3.1.2] System Under Test (SUT) [Ref.[Ma98], section 3.1.2]
Out-of-Order Packet [Ref.[Po06], section 3.3.4] Out-of-Order Packet [Ref.[Po06], section 3.3.4]
Duplicate Packet [Ref.[Po06], section 3.3.5] Duplicate Packet [Ref.[Po06], section 3.3.5]
Packet Reordering [Ref.[Mo06], section 3.3] Packet Reordering [Ref.[Mo06], section 3.3]
Stream [Ref.[Po06], section 3.3.2] Stream [Ref.[Po06], section 3.3.2]
Forwarding Delay [Ref.[Po06], section 3.2.4] Forwarding Delay [Ref.[Po06], section 3.2.4]
Jitter [Ref.[Po06], section 3.2.5] IP Packet Delay Variation (IPDV) [Ref.[De02], section 1.2]
Loss Period [Ref.[Ko02], section 4] Loss Period [Ref.[Ko02], section 4]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 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 [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 intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
3. Term Definitions 3. Term Definitions
skipping to change at page 13, line 37 skipping to change at page 12, line 37
The destination addresses for the Offered Load MUST be distributed The destination addresses for the Offered Load MUST be distributed
such that all routes or a statistically representative subset of all such that all routes or a statistically representative subset of all
routes are matched and each of these routes is offered an equal share 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 of the Offered Load. It is RECOMMENDED to send traffic to all
routes, but a statistically representative subset of all routes can routes, but a statistically representative subset of all routes can
be used if required. be used if required.
At least one packet per route for all routes matched in the Offered 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. Load MUST be offered to the DUT within each Packet Sampling Interval.
For maximum accuracy the value for the Packet Sampling Interval For maximum accuracy the value for the Packet Sampling Interval
SHOULD be as small as possible, but the presence of Jitter [Po06] may SHOULD be as small as possible, but the presence of IP Packet Delay
enforce using a larger Packet Sampling Interval. Variation (IPDV) [De02] may enforce using a larger Packet Sampling
Interval.
The Offered Load, Jitter, the number of routes, and the Packet The Offered Load, IPDV, the number of routes, and the Packet Sampling
Sampling Interval influence the observations for the Rate-Derived Interval influence the observations for the Rate-Derived Method. It
Method. It may be difficult to identify the different convergence may be difficult to identify the different convergence time instants
time instants in the Rate-Derived Convergence Graph. For example, it in the Rate-Derived Convergence Graph. For example, it is possible
is possible that a Convergence Event causes the Forwarding Rate to that a Convergence Event causes the Forwarding Rate to drop to zero,
drop to zero, while this may not be observed in the Forwarding Rate while this may not be observed in the Forwarding Rate measurements if
measurements if the Packet Sampling Interval is too large. the Packet Sampling Interval is too large.
Jitter causes fluctuations in the number of received packets during IPDV causes fluctuations in the number of received packets during
each Packet Sampling Interval. To account for the presence of Jitter each Packet Sampling Interval. To account for the presence of IPDV
in determining if a convergence instant has been reached, Jitter in determining if a convergence instant has been reached, Forwarding
SHOULD be observed during each Packet Sampling Interval. The minimum Delay SHOULD be observed during each Packet Sampling Interval. The
and maximum number of packets expected in a Packet Sampling Interval minimum and maximum number of packets expected in a Packet Sampling
in presence of Jitter can be calculated with Equation 1. Interval in presence of IPDV can be calculated with Equation 1.
number of packets expected in a Packet Sampling Interval number of packets expected in a Packet Sampling Interval
in presence of Jitter in presence of IP Packet Delay Variation
= expected number of packets without Jitter = expected number of packets without IP Packet Delay Variation
+/-(max Jitter during Packet Sampling Interval * Offered Load) +/-( (maxDelay - minDelay) * Offered Load)
with minDelay and maxDelay the minimum resp. maximum Forwarding Delay
of packets received during the Packet Sampling Interval
Equation 1 Equation 1
To determine if a convergence instant has been reached the number of To determine if a convergence instant has been reached the number of
packets received in a Packet Sampling Interval is compared with the packets received in a Packet Sampling Interval is compared with the
range of expected number of packets calculated in Equation 1. range of expected number of packets calculated in Equation 1.
If packets are going over multiple ECMP members and one or more of
the members has failed then the number of received packets during
each Packet Sampling Interval may vary, even excluding presence of
IPDV. To prevent fluctuation of the number of received packets
during each Packet Sampling Interval for this reason, the Packet
Sampling Interval duration SHOULD be a whole multiple of the time
between two consecutive packets sent to the same destination.
Metrics measured at the Packet Sampling Interval MUST include Metrics measured at the Packet Sampling Interval MUST include
Forwarding Rate and packet loss. Forwarding Rate and packet loss.
Rate-Derived Method is a RECOMMENDED method to measure convergence Rate-Derived Method is a RECOMMENDED method to measure convergence
time benchmarks. time benchmarks.
To measure convergence time benchmarks for Convergence Events that do To measure convergence time benchmarks for Convergence Events that do
not cause instantaneous traffic loss for all routes at the not cause instantaneous traffic loss for all routes at the
Convergence Event Instant, the Tester SHOULD collect a timestamp of Convergence Event Instant, the Tester SHOULD collect a timestamp of
the Convergence Event Instant and the Tester SHOULD observe the Convergence Event Instant and the Tester SHOULD observe
skipping to change at page 17, line 32 skipping to change at page 16, line 44
Instant and the Convergence Recovery Instant, as shown in Equation 2. Instant and the Convergence Recovery Instant, as shown in Equation 2.
Full Convergence Time = Full Convergence Time =
Convergence Recovery Instant - Convergence Event Instant Convergence Recovery Instant - Convergence Event Instant
Equation 2 Equation 2
The Convergence Event Instant can be derived from the Forwarding Rate The Convergence Event Instant can be derived from the Forwarding Rate
observation or from a timestamp collected by the Tester. observation or from a timestamp collected by the Tester.
For the testcases described in [Po09m], it is expected that Full For the testcases described in [Po10m], it is expected that Full
Convergence Time equals the maximum Route-Specific Convergence Time Convergence Time equals the maximum Route-Specific Convergence Time
when benchmarking all routes in FIB using the Route-Specific Loss- when benchmarking all routes in FIB using the Route-Specific Loss-
Derived Method. Derived Method.
It is not possible to measure Full Convergence Time using the Loss- It is not possible to measure Full Convergence Time using the Loss-
Derived Method. Derived Method.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived
Method Method
3.6.2. First Route Convergence Time 3.6.2. First Route Convergence Time
Definition: Definition:
skipping to change at page 18, line 24 skipping to change at page 17, line 34
Equation 3. Equation 3.
First Route Convergence Time = First Route Convergence Time =
First Route Convergence Instant - Convergence Event Instant First Route Convergence Instant - Convergence Event Instant
Equation 3 Equation 3
The Convergence Event Instant can be derived from the Forwarding Rate The Convergence Event Instant can be derived from the Forwarding Rate
observation or from a timestamp collected by the Tester. observation or from a timestamp collected by the Tester.
For the testcases described in [Po09m], it is expected that First For the testcases described in [Po10m], it is expected that First
Route Convergence Time equals the minimum Route-Specific Convergence Route Convergence Time equals the minimum Route-Specific Convergence
Time when benchmarking all routes in FIB using the Route-Specific Time when benchmarking all routes in FIB using the Route-Specific
Loss-Derived Method. Loss-Derived Method.
It is not possible to measure First Route Convergence Time using the It is not possible to measure First Route Convergence Time using the
Loss-Derived Method. Loss-Derived Method.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
skipping to change at page 19, line 43 skipping to change at page 19, line 7
The Convergence Event Instant and Traffic Start Instant SHOULD be The Convergence Event Instant and Traffic Start Instant SHOULD be
collected by the Tester. collected by the Tester.
The Route-Specific Convergence Time benchmarks enable minimum, The Route-Specific Convergence Time benchmarks enable minimum,
maximum, average, and median convergence time measurements to be maximum, average, and median convergence time measurements to be
reported by comparing the results for the different route entries. reported by comparing the results for the different route entries.
It also enables benchmarking of convergence time when configuring a It also enables benchmarking of convergence time when configuring a
priority value for route entry(ies). Since multiple Route-Specific priority value for route entry(ies). Since multiple Route-Specific
Convergence Times can be measured it is possible to have an array of Convergence Times can be measured it is possible to have an array of
results. The format for reporting Route-Specific Convergence Time is results. The format for reporting Route-Specific Convergence Time is
provided in [Po09m]. provided in [Po10m].
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
See Also: See Also:
Convergence Event, Convergence Packet Loss, Connectivity Packet Loss, Convergence Event, Convergence Packet Loss, Connectivity Packet Loss,
Route Convergence Route Convergence
skipping to change at page 21, line 25 skipping to change at page 20, line 42
In general the Route Loss of Connectivity Period is not equal to the In general the Route Loss of Connectivity Period is not equal to the
Route-Specific Convergence Time. If the DUT continues to forward Route-Specific Convergence Time. If the DUT continues to forward
traffic to the Preferred Egress Interface after the Convergence Event traffic to the Preferred Egress Interface after the Convergence Event
is applied then the Route Loss of Connectivity Period will be smaller is applied then the Route Loss of Connectivity Period will be smaller
than the Route-Specific Convergence Time. This is also specifically than the Route-Specific Convergence Time. This is also specifically
the case after reversing a failure event. the case after reversing a failure event.
The Route Loss of Connectivity Period may be equal to the Route- The Route Loss of Connectivity Period may be equal to the Route-
Specific Convergence Time if, 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 Event, traffic for all routes starts dropping instantaneously on the
Convergence Event Instant. See discussion in [Po09m]. Convergence Event Instant. See discussion in [Po10m].
For the testcases described in [Po09m] the Route Loss of Connectivity For the testcases described in [Po10m] the Route Loss of Connectivity
Period is expected to be a single Loss Period [Ko02]. Period is expected to be a single Loss Period [Ko02].
When benchmarking Route Loss of Connectivity Period, Connectivity When benchmarking Route Loss of Connectivity Period, Connectivity
Packet Loss is measured for each route and Equation 8 is applied for Packet Loss is measured for each route and Equation 8 is applied for
each measured route entry. The calculation is equal to Equation 4 in each measured route entry. The calculation is equal to Equation 4 in
Section 3.6.3. Section 3.6.3.
Route Loss of Connectivity Period = Route Loss of Connectivity Period =
Connectivity Packet Loss for specific route/Offered Load per route Connectivity Packet Loss for specific route/Offered Load per route
skipping to change at page 22, line 27 skipping to change at page 21, line 44
forward traffic to the Preferred Egress Interface after the forward traffic to the Preferred Egress Interface after the
Convergence Event is applied then the Loss-Derived Loss of Convergence Event is applied then the Loss-Derived Loss of
Connectivity Period will be smaller than the Loss-Derived Convergence Connectivity Period will be smaller than the Loss-Derived Convergence
Time. This is also specifically the case after reversing a failure Time. This is also specifically the case after reversing a failure
event. event.
The Loss-Derived Loss of Connectivity Period may be equal to the The Loss-Derived Loss of Connectivity Period may be equal to the
Loss-Derived Convergence Time if, as a characteristic of the Loss-Derived Convergence Time if, as a characteristic of the
Convergence Event, traffic for all routes starts dropping Convergence Event, traffic for all routes starts dropping
instantaneously on the Convergence Event Instant. See discussion in instantaneously on the Convergence Event Instant. See discussion in
[Po09m]. [Po10m].
For the testcases described in [Po09m] each route's Route Loss of For the testcases described in [Po10m] each route's Route Loss of
Connectivity Period is expected to be a single Loss Period [Ko02]. Connectivity Period is expected to be a single Loss Period [Ko02].
When benchmarking Loss-Derived Loss of Connectivity Period, When benchmarking Loss-Derived Loss of Connectivity Period,
Connectivity Packet Loss is measured for all routes and Equation 9 is Connectivity Packet Loss is measured for all routes and Equation 9 is
applied. The calculation is equal to Equation 6 in Section 3.6.4. applied. The calculation is equal to Equation 6 in Section 3.6.4.
Loss-Derived Loss of Connectivity Period = Loss-Derived Loss of Connectivity Period =
Connectivity Packet Loss for all routes/Offered Load Connectivity Packet Loss for all routes/Offered Load
Equation 9 Equation 9
skipping to change at page 25, line 27 skipping to change at page 24, line 41
Forwarding Rate and received packets. 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 Rate-Derived Method. This is particularly true observed with the Rate-Derived Method. This is particularly true
when implementations complete Full Convergence in less time than the when implementations complete Full Convergence in less time than the
Packet Sampling Interval. The Convergence Event Instant and First Packet Sampling Interval. The Convergence Event Instant and First
Route Convergence Instant may not be easily identifiable and the Route Convergence Instant may not be easily identifiable and the
Rate-Derived Method may produce a larger than actual convergence Rate-Derived Method may produce a larger than actual convergence
time. time.
Using a small Packet Sampling Interval in the presence of Jitter Using a small Packet Sampling Interval in the presence of IPDV [De02]
[Po06] may cause fluctuations of the Forwarding Rate observation and may cause fluctuations of the Forwarding Rate observation and can
can prevent correct observation of the different convergence time prevent correct observation of the different convergence time
instants. instants.
The value of the Packet Sampling Interval only contributes to the The value of the Packet Sampling Interval only contributes to the
measurement accuracy of the Rate-Derived Method. For maximum measurement accuracy of the Rate-Derived Method. For maximum
accuracy the value for the Packet Sampling Interval SHOULD be as accuracy the value for the Packet Sampling Interval SHOULD be as
small as possible, but the presence of Jitter may enforce using a small as possible, but the presence of IPDV may enforce using a
larger Packet Sampling Interval. larger Packet Sampling Interval.
Measurement Units: seconds Measurement Units: seconds
Issues: None Issues: None
See Also: Rate-Derived Method See Also: Rate-Derived Method
3.7.6. Sustained Convergence Validation Time 3.7.6. Sustained Convergence Validation Time
Definition: Definition:
The amount of time for which the completion of Full Convergence is The amount of time for which the completion of Full Convergence is
maintained without additional packet loss. maintained without additional packet loss.
skipping to change at page 26, line 27 skipping to change at page 25, line 39
Issues: None Issues: None
See Also: See Also:
Full Convergence, Convergence Recovery Instant Full Convergence, Convergence Recovery Instant
3.7.7. Forwarding Delay Threshold 3.7.7. Forwarding Delay Threshold
Definition: Definition:
The maximum Forwarding Delay for a packet to be accepted. The maximum waiting time threshold used to distinguish between
packets with very long delay and lost packets that will never arrive.
Discussion: Discussion:
Applying a Forwarding Delay Threshold allows to consider packets with Applying a Forwarding Delay Threshold allows to consider packets with
a too large Forwarding Delay as being lost, as is required for some a too large Forwarding Delay as being lost, as is required for some
applications (e.g. voice, video, etc.). The Forwarding Delay applications (e.g. voice, video, etc.). The Forwarding Delay
Threshold is a parameter of the methodology, if it is applied it MUST Threshold is a parameter of the methodology, if it is applied it MUST
be reported. be reported.
Measurement Units: seconds Measurement Units: seconds
skipping to change at page 28, line 39 skipping to change at page 28, line 8
[Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[Ca90] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual [Ca90] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
environments", RFC 1195, December 1990. environments", RFC 1195, December 1990.
[Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for [Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
IPv6", RFC 5340, July 2008. IPv6", RFC 5340, July 2008.
[De02] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008. October 2008.
[Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample [Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, August 2002. Metrics", RFC 3357, August 2002.
[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching
Devices", RFC 2285, February 1998. Devices", RFC 2285, February 1998.
[Mo06] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., [Mo06] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S.,
skipping to change at page 29, line 17 skipping to change at page 28, line 36
[Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, [Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
"Terminology for Benchmarking Network-layer Traffic Control "Terminology for Benchmarking Network-layer Traffic Control
Mechanisms", RFC 4689, October 2006. Mechanisms", RFC 4689, October 2006.
[Po09a] Poretsky, S., "Considerations for Benchmarking Link-State [Po09a] Poretsky, S., "Considerations for Benchmarking Link-State
IGP Data Plane Route Convergence", IGP Data Plane Route Convergence",
draft-ietf-bmwg-igp-dataplane-conv-app-17 (work in draft-ietf-bmwg-igp-dataplane-conv-app-17 (work in
progress), March 2009. progress), March 2009.
[Po09m] Poretsky, S. and B. Imhoff, "Benchmarking Methodology for [Po10m] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking
Link-State IGP Data Plane Route Convergence", Methodology for Link-State IGP Data Plane Route
draft-ietf-bmwg-igp-dataplane-conv-meth-18 (work in Convergence", draft-ietf-bmwg-igp-dataplane-conv-meth-20
progress), July 2009. (work in progress), March 2010.
7.2. Informative References 7.2. Informative References
[Ca01] Casner, S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained [Ca01] Casner, S., Alaettinoglu, C., and C. Kuan, "A Fine-Grained
View of High Performance Networking", NANOG 22, June 2001. View of High Performance Networking", NANOG 22, June 2001.
[Ci03] Ciavattone, L., Morton, A., and G. Ramachandran, [Ci03] Ciavattone, L., Morton, A., and G. Ramachandran,
"Standardized Active Measurements on a Tier 1 IP Backbone", "Standardized Active Measurements on a Tier 1 IP Backbone",
IEEE Communications Magazine p90-97, May 2003. IEEE Communications Magazine p90-97, May 2003.
 End of changes. 37 change blocks. 
109 lines changed or deleted 117 lines changed or added

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