RFC 6412
Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence
RFC 6412: Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence 🦋
Okay bestie, let's start with the header stuff 🎀. This is RFC 6412, published by the IETF (Internet Engineering Task Force) in November 2011. The authors are S. Poretsky (Allot Communications), B. Imhoff (F5 Networks), and K. Michielsen (Cisco Systems). It's classed as Informational 📖, which means it's published for information and is not a Standards Track spec. The ISSN is 2070-1721. Its header doesn't list any RFCs it obsoletes or updates, so no drama there 💜.
Abstract ✨
This doc is all about the vocab for benchmarking how fast a link-state Interior Gateway Protocol (IGP) gets its routes converged 🚀. The whole point is to measure IGP convergence time from the outside, using black-box data-plane measurements, so you're watching the traffic and not peeking inside the box. The terms work for any link-state IGP, and the examples given are IS-IS and OSPF 🌈.
Status of This Memo 📜
First things first: this is not an Internet Standards Track spec 🙈. It's published for information only.
It's still an IETF product, though, and it reflects the consensus of the IETF community. It went through public review and was approved by the Internet Engineering Steering Group (IESG). Not everything the IESG approves is eligible for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🧐.
For the current status, errata, and a way to send feedback, head to http://www.rfc-editor.org/info/rfc6412 🔗.
Copyright Notice 🎀
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 💖.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the publication date. Please actually read those, because they spell out your rights and restrictions. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 📝.
This document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. Unless you've got an adequate license from those copyright holders, 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. The exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍.
Table of Contents 🌸
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 4
3. Term Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Route Convergence . . . . . . . . . . . . . . . . . . 5
3.1.2. Full Convergence . . . . . . . . . . . . . . . . . . . 5
3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Traffic Start Instant . . . . . . . . . . . . . . . . 6
3.2.2. Convergence Event Instant . . . . . . . . . . . . . . 6
3.2.3. Convergence Recovery Instant . . . . . . . . . . . . . 7
3.2.4. First Route Convergence Instant . . . . . . . . . . . 8
3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Convergence Event Transition . . . . . . . . . . . . . 8
3.3.2. Convergence Recovery Transition . . . . . . . . . . . 9
3.4. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Local Interface . . . . . . . . . . . . . . . . . . . 10
3.4.2. Remote Interface . . . . . . . . . . . . . . . . . . . 10
3.4.3. Preferred Egress Interface . . . . . . . . . . . . . . 10
3.4.4. Next-Best Egress Interface . . . . . . . . . . . . . . 11
3.5. Benchmarking Methods . . . . . . . . . . . . . . . . . . . 11
3.5.1. Rate-Derived Method . . . . . . . . . . . . . . . . . 11
3.5.2. Loss-Derived Method . . . . . . . . . . . . . . . . . 14
3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 15
3.6. Benchmarks . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.1. Full Convergence Time . . . . . . . . . . . . . . . . 17
3.6.2. First Route Convergence Time . . . . . . . . . . . . . 18
3.6.3. Route-Specific Convergence Time . . . . . . . . . . . 18
3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 20
3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 21
3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 22
3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 23
3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 23
3.7.2. Convergence Packet Loss . . . . . . . . . . . . . . . 23
3.7.3. Connectivity Packet Loss . . . . . . . . . . . . . . . 24
3.7.4. Packet Sampling Interval . . . . . . . . . . . . . . . 24
3.7.5. Sustained Convergence Validation Time . . . . . . . . 25
3.7.6. Forwarding Delay Threshold . . . . . . . . . . . . . . 26
3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 26
3.8.1. Impaired Packet . . . . . . . . . . . . . . . . . . . 26
4. Security Considerations . . . . . . . . . . . . . . . . . . . 27
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
6. Normative References . . . . . . . . . . . . . . . . . . . . . 271. Introduction and Scope 🧚
This doc is a companion to [Po11m], which holds the methodology for benchmarking link-state Interior Gateway Protocol (IGP) convergence by watching the data plane 👀. This one's job is to introduce the new terms you need to actually run the Link-State IGP Data-Plane Route Convergence methodology [Po11m] 💅.
IGP convergence time gets measured by observing the data plane through the Device Under Test (DUT) at the Tester 🧪. The methodology and terminology can be applied to IPv4 and IPv6 traffic, and to link-state IGPs like Intermediate System to Intermediate System (IS-IS) [Ca90][Ho08], Open Shortest Path First (OSPF) [Mo98] [Co08], and others 🌐.
2. Existing Definitions 💅
This doc borrows terms that are already defined in other IETF documents. Here are some examples, though the list isn't limited to these 📚:
Throughput [Br91], Section 3.17
Offered Load [Ma98], Section 3.5.2
Forwarding Rate [Ma98], Section 3.6.1
Device Under Test (DUT) [Ma98], Section 3.1.1
System Under Test (SUT) [Ma98], Section 3.1.2
Out-of-Order Packet [Po06], Section 3.3.4
Duplicate Packet [Po06], Section 3.3.5
Stream [Po06], Section 3.3.2
Forwarding Delay [Po06], Section 3.2.4
IP Packet Delay Variation (IPDV) [De02], Section 1.2
Loss Period [Ko02], Section 4Now the keyword rule 🔑. The keywords "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 how these keywords are used to make the intent of Standards Track documents as clear as possible. This document uses them too, but it is not a Standards Track document 🧐.
3. Term Definitions 👑
3.1. Convergence Types 🌈
3.1.1. Route Convergence 🛣️
Definition: 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) so that forwarding for a route entry works on the Next-Best Egress Interface (Section 3.4.4) ✨.
Discussion: Generally, IGP convergence doesn't have to change forwarding. But the test cases in [Po11m] are set up so that IGP convergence does change the egress interface for the measurement data-plane traffic 🔁. Because of that property, Route Convergence can be seen from the outside, as the measurement traffic gets rerouted to the Next-Best Egress Interface (Section 3.4.4) 🦋.
Measurement Units: N/A
See Also: Next-Best Egress Interface, Full Convergence
3.1.2. Full Convergence 💖
Definition: Route Convergence for all routes in the Forwarding Information Base (FIB) 🫶.
Discussion: Generally, IGP convergence doesn't have to change forwarding. But the test cases in [Po11m] are set up so that IGP convergence does change the egress interface for the measurement data-plane traffic 🔁. Because of that property of the test case specifications, Full Convergence can be seen from the outside, as the measurement traffic gets rerouted to the Next-Best Egress Interface (Section 3.4.4) 🌸.
Measurement Units: N/A
See Also: Next-Best Egress Interface, Route Convergence
3.2. Instants ⏰
3.2.1. Traffic Start Instant 🚦
Definition: The time instant the Tester sends out the first data packet to the DUT 📤.
Discussion: If you're benchmarking IGP convergence time with the Loss-Derived Method (Section 3.5.2) or the Route-Specific Loss-Derived Method (Section 3.5.3), and the Convergence Event (Section 3.7.1) you applied doesn't cause instant traffic loss for all routes at the Convergence Event Instant (Section 3.2.2), then the Tester SHOULD collect a timestamp at the Traffic Start Instant 🕰️. That lets you measure the time between the Traffic Start Instant and the Convergence Event Instant 🧮.
Measurement Units: seconds (and fractions), reported with resolution sufficient to distinguish between different instants
See Also: Loss-Derived Method, Route-Specific Loss-Derived Method, Convergence Event, Convergence Event Instant
3.2.2. Convergence Event Instant 💥
Definition: The time instant that a Convergence Event (Section 3.7.1) occurs 🎯.
Discussion: If the Convergence Event (Section 3.7.1) causes instant traffic loss on the Preferred Egress Interface (Section 3.4.3), the Convergence Event Instant can be observed in the data plane as the moment no more packets arrive on the Preferred Egress Interface 📉.
If the Convergence Event does not cause instant traffic loss on the Preferred Egress Interface (Section 3.4.3), the Tester SHOULD collect a timestamp at the Convergence Event Instant 🫧.
Measurement Units: seconds (and fractions), reported with resolution sufficient to distinguish between different instants
See Also: Convergence Event, Preferred Egress Interface
3.2.3. Convergence Recovery Instant 🦋
Definition:
The time instant that Full Convergence (Section 3.1.2) has completed. ✨
Discussion:
okay so the Full Convergence completed state MUST be held for a stretch of time equal to the Sustained Convergence Validation Time (Section 3.7.5) 🫶 that's how you validate the Convergence Recovery Instant. no skipping this part bestie 😭
the Convergence Recovery Instant is visible from the data plane: it's the moment the DUT is forwarding traffic to every destination over the Next-Best Egress Interface (Section 3.4.4) with no impairments. iconic, ngl 💅
Measurement Units:
seconds (and fractions), reported with resolution sufficient to distinguish between different instants 🌸
See Also:
Sustained Convergence Validation Time, Full Convergence, Next-Best Egress Interface
3.2.4. First Route Convergence Instant 🧚
Definition:
The time instant the first route entry completes Route Convergence (Section 3.1.1). 👑
Discussion:
any route can be the first one to finish Route Convergence, so it's kind of a race 🏃♀️ The First Route Convergence Instant is visible from the data plane as the instant the first packet that is not an Impaired Packet (Section 3.8.1) comes in from the Next-Best Egress Interface (Section 3.4.4). BUT, for the test cases with Equal Cost Multi-Path (ECMP) or Parallel Links, it's instead the instant the Forwarding Rate on the Next-Best Egress Interface (Section 3.4.4) starts to go up. two ways to spot it, both slay 🔥
Measurement Units:
seconds (and fractions), reported with resolution sufficient to distinguish between different instants ⭐
See Also:
Route Convergence, Impaired Packet, Next-Best Egress Interface
3.3. Transitions 🌈
3.3.1. Convergence Event Transition 💜
Definition:
A time interval following a Convergence Event (Section 3.7.1) in which the Forwarding Rate on the Preferred Egress Interface (Section 3.4.3) gradually drops to zero. 📉
Discussion:
the Forwarding Rate during a Convergence Event Transition may or may not decrease linearly. it's giving unpredictable 🙈
the Forwarding Rate observed on the DUT egress interface(s) may or may not decrease to zero. same energy, no promises 💀
the Offered Load, the number of routes, and the Packet Sampling Interval (Section 3.7.4) all influence what you see during the Convergence Event Transition when you use the Rate-Derived Method (Section 3.5.1). so many moving parts 😭🫶
Measurement Units:
seconds (and fractions) ⏱️
See Also:
Convergence Event, Preferred Egress Interface, Packet Sampling Interval, Rate-Derived Method
3.3.2. Convergence Recovery Transition 🍓
Definition:
A time interval following the First Route Convergence Instant (Section 3.4.4) in which the Forwarding Rate on the DUT egress interface(s) gradually climbs up to equal the Offered Load. 📈
Discussion:
the Forwarding Rate observed during a Convergence Recovery Transition may or may not increase linearly. again, not guaranteed, bestie 🦋
the Offered Load, the number of routes, and the Packet Sampling Interval (Section 3.7.4) influence what you observe during the Convergence Recovery Transition when you use the Rate-Derived Method (Section 3.5.1). it's the same crew of factors, just in reverse vibes 🔄
Measurement Units:
seconds (and fractions) ⏱️
See Also:
First Route Convergence Instant, Packet Sampling Interval, Rate-Derived Method
3.4. Interfaces 🎀
3.4.1. Local Interface 🏠
Definition:
An interface on the DUT. 💖
Discussion:
a failure of a Local Interface tells you the failure happened directly on the DUT. that's the culprit, no cap 🫵
Measurement Units:
N/A
See Also:
Remote Interface
3.4.2. Remote Interface 🌍
Definition:
An interface on a neighboring router that is not directly connected to any interface on the DUT. 👀
Discussion:
a failure of a Remote Interface tells you the failure happened on a neighbor router's interface that isn't directly connected to the DUT. not the DUT's fault, lowkey a relief 😌
Measurement Units:
N/A
See Also:
Local Interface
3.4.3. Preferred Egress Interface ⭐
Definition:
The outbound interface from the DUT for traffic routed to the preferred next-hop. 🚪
Discussion:
the Preferred Egress Interface is the egress interface you're using before a Convergence Event (Section 3.7.1). it's the old favorite, the main character 👑
Measurement Units:
N/A
See Also:
Convergence Event, Next-Best Egress Interface
3.4.4. Next-Best Egress Interface 🥈
Definition:
The outbound interface or set of outbound interfaces in an Equal Cost Multipath (ECMP) set or parallel link set of the Device Under Test (DUT) for traffic routed to the second-best next-hop. 🦢
Discussion:
the Next-Best Egress Interface becomes the egress interface after a Convergence Event (Section 3.4.4). the backup queen steps up 👸
for the test cases in [Po11m] that use test topologies with an ECMP set or parallel link set, the term Preferred Egress Interface refers to all members of the link set. so the whole squad counts together 🫶
Measurement Units:
N/A
See Also:
Convergence Event, Preferred Egress Interface
3.5. Benchmarking Methods 🧁
3.5.1. Rate-Derived Method 📊
Definition:
The method for calculating convergence time benchmarks by observing the Forwarding Rate each Packet Sampling Interval (Section 3.7.4). 🧮
Discussion:
Figure 1 shows an example of how the Forwarding Rate changes over time during convergence when you're using the Rate-Derived Method. the graph is giving drama 🎭
^ Traffic Convergence
Fwd | Start Recovery
Rate | Instant Instant
| Offered ^ ^
| Load --> ----------\ /-----------
| \ /<--- Convergence
| \ Packet / Recovery
| Convergence --->\ Loss / Transition
| Event \ /
| Transition \---------/ <-- Max Packet Loss
|
+--------------------------------------------------------->
^ ^ time
Convergence First Route
Event Instant Convergence Instant
Figure 1: Rate-Derived Convergence Graphto collect statistics on Out-of-Order Packets per flow (see [Th00], Section 3), the Offered Load SHOULD consist of multiple Streams [Po06], and each Stream SHOULD consist of a single flow . if you're sending multiple Streams, the measured traffic statistics for all Streams MUST be added together. adding it all up, periodt 🧾
the destination addresses for the Offered Load MUST be spread out so that all routes, or a statistically representative subset of all routes, get matched, and each of those routes gets an equal share of the Offered Load. fair is fair 🤝 It is RECOMMENDED to send traffic to all routes, but a statistically representative subset of all routes can be used if required. 🌟
at least one packet per route for all routes matched in the Offered Load MUST be offered to the DUT within each Packet Sampling Interval. for maximum accuracy, the Packet Sampling Interval SHOULD be as small as possible, but IP Packet Delay Variation (IPDV) [De02] may mean you need a larger Packet Sampling Interval. the IPDV struggle is real 😩
the Offered Load, IPDV, the number of routes, and the Packet Sampling Interval all influence the observations for the Rate-Derived Method. it can be hard to pick out the different convergence time instants on the Rate-Derived Convergence Graph. for example, a Convergence Event might make the Forwarding Rate drop to zero, but you might not see that in the Forwarding Rate measurements if the Packet Sampling Interval is too large. sneaky, right? 🕵️♀️
IPDV causes the number of received packets to fluctuate during each Packet Sampling Interval. to account for IPDV when deciding whether a convergence instant has been reached, Forwarding Delay SHOULD be observed during each Packet Sampling Interval. the minimum and maximum number of packets expected in a Packet Sampling Interval in the presence of IPDV can be calculated with Equation 1. ✨
number of packets expected in a Packet Sampling Interval
in presence of IP Packet Delay Variation
= expected number of packets without IP Packet Delay Variation
+/-( (maxDelay - minDelay) * Offered Load)
where minDelay and maxDelay indicate (respectively) the minimum and
maximum Forwarding Delay of packets received during the Packet
Sampling Interval
Equation 1to decide whether a convergence instant has been reached, compare the number of packets received in a Packet Sampling Interval with the range of expected packets calculated in Equation 1. math but make it cute 🎀
if packets are going over multiple ECMP members and one or more of those members has failed, the number of received packets during each Packet Sampling Interval may vary, even without IPDV. to stop the count from bouncing around 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 Forwarding Rate and Impaired Packet count. no skipping these, bestie 💅
to measure convergence time benchmarks for Convergence Events (Section 3.7.1) 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 (Section 3.2.2), and the Tester SHOULD observe Forwarding Rate separately on the Next-Best Egress Interface. ⏰ two timestamps, double the receipts 🧾
since the Rate-Derived Method does not tell individual traffic destinations apart, it SHOULD NOT be used for any route specific measurements. so the Rate-Derived Method SHOULD NOT be used to benchmark Route Loss of Connectivity Period (Section 3.6.5). not for that one, babe 🙅♀️
Measurement Units:
N/A
See Also:
Packet Sampling Interval, Convergence Event, Convergence Event Instant, Next-Best Egress Interface, Route Loss of Connectivity Period
3.5.2. Loss-Derived Method ✨
Definition:
The method to calculate the Loss-Derived Convergence Time (Section 3.6.4) and Loss-Derived Loss of Connectivity Period (Section 3.6.6) benchmarks from the amount of Impaired Packets (Section 3.8.1). 💖
Discussion:
Okay so, to collect stats on Out-of-Order Packets per flow (see [Th00], Section 3), the Offered Load SHOULD consist of multiple Streams [Po06], and each Stream SHOULD consist of a single flow . 🧚 If you're sending multiple Streams, the measured traffic statistics for all Streams MUST be added together. No skipping that part, bestie! 🫶
The destination addresses for the Offered Load MUST be spread out so that all routes, or a statistically representative subset of all routes, get matched, and each of those routes gets an equal share of the Offered Load. ✨ It is RECOMMENDED to send traffic to all routes, but a statistically representative subset of all routes can be used if required. 🌸
The Loss-Derived Method SHOULD always be paired with the Rate-Derived Method so you can see Full Convergence completion. 🔥 The total amount of Convergence Packet Loss gets collected after Full Convergence completion.
Now for convergence time and loss of connectivity benchmarks on Convergence Events that cause instantaneous traffic loss for all routes at the Convergence Event Instant: the Tester SHOULD observe the Impaired Packet count on all DUT egress interfaces (see Connectivity Packet Loss (Section 3.7.3)). 👑
And for convergence time benchmarks on Convergence Events that do not cause instantaneous traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD collect timestamps of the Start Traffic Instant and of the Convergence Event Instant, and the Tester SHOULD observe the Impaired Packet count separately on the Next-Best Egress Interface (see Convergence Packet Loss (Section 3.7.2)). 🦋
Since the Loss-Derived Method doesn't distinguish between traffic destinations, and the Impaired Packet stats are only collected after Full Convergence completion, this method can only measure average values over all routes. 💅 That's why the Loss-Derived Method can only be used to benchmark Loss-Derived Convergence Time (Section 3.6.4) and Loss-Derived Loss of Connectivity Period (Section 3.6.6). Main character energy for averages, but no per-route tea here. 🍓
Note that the Loss-Derived Method measures an average over all routes, including the routes that may not be impacted by the Convergence Event, such as routes via non-impacted members of ECMP or parallel links. 🙈
Measurement Units:
N/A
See Also:
Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity Period, Connectivity Packet Loss, Convergence Packet Loss
3.5.3. Route-Specific Loss-Derived Method 🎀
Definition:
The method to calculate the Route-Specific Convergence Time (Section 3.6.3) benchmark from the amount of Impaired Packets (Section 3.8.1) during convergence for a specific route entry. 🌈
Discussion:
To benchmark Route-Specific 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 all routes or a statistically representative subset of all routes. 💜 Each Stream SHOULD consist of a single flow (see [Th00], Section 3). Convergence Packet Loss is measured for each Stream separately. It's giving organized. ✨
The Route-Specific Loss-Derived Method SHOULD always be combined with the Rate-Derived Method in order to observe Full Convergence completion. 🔥 The total amount of Convergence Packet Loss (Section 3.7.2) for each Stream is collected after Full Convergence completion.
The Route-Specific Loss-Derived Method is the RECOMMENDED method to measure convergence time benchmarks. 👑🫶 Literally the one to pick!
For convergence time and loss of connectivity benchmarks on Convergence Events that cause instantaneous traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD observe the Impaired Packet count on all DUT egress interfaces (see Connectivity Packet Loss (Section 3.7.3)). 💖
For convergence time benchmarks on Convergence Events that do not cause instantaneous traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD collect timestamps of the Start Traffic Instant and of the Convergence Event Instant, and the Tester SHOULD observe packet loss separately on the Next-Best Egress Interface (see Convergence Packet Loss (Section 3.7.2)). 🦋
Since the Route-Specific Loss-Derived Method uses traffic streams to individual routes, it observes the Impaired Packet count the way a network user would actually experience it. 🥹 That's why the Route-Specific Loss-Derived Method is RECOMMENDED to measure Route-Specific Convergence Time benchmarks and Route Loss of Connectivity Period benchmarks. Iconic. 💅
Measurement Units:
N/A
See Also:
Route-Specific Convergence Time, Route Loss of Connectivity Period, Connectivity Packet Loss, Convergence Packet Loss
3.6. Benchmarks 🍰
3.6.1. Full Convergence Time ⏱️
Definition:
The time duration of the period between the Convergence Event Instant and the Convergence Recovery Instant as observed using the Rate-Derived Method. 🌸
Discussion:
Using the Rate-Derived 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 2. 🧮
Full Convergence Time =
Convergence Recovery Instant - Convergence Event Instant
Equation 2The Convergence Event Instant can be derived from the Forwarding Rate observation or from a timestamp collected by the Tester. 🫧
For the test cases described in [Po11m], it is expected that Full Convergence Time equals the maximum Route-Specific Convergence Time when benchmarking all routes in the FIB using the Route-Specific Loss-Derived Method. 💜
It is not possible to measure Full Convergence Time using the Loss-Derived Method. Sorry, bestie! 😭
Measurement Units:
seconds (and fractions)
See Also:
Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived Method, Convergence Event Instant, Convergence Recovery Instant
3.6.2. First Route Convergence Time 🏃♀️💨
Definition:
The duration of the period between the Convergence Event Instant and the First Route Convergence Instant as observed using the Rate-Derived Method. 🦋
Discussion:
Using the Rate-Derived 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 3. ✨
First Route Convergence Time =
First Route Convergence Instant - Convergence Event Instant
Equation 3The Convergence Event Instant can be derived from the Forwarding Rate observation or from a timestamp collected by the Tester. 🌷
For the test cases described in [Po11m], it is expected that First Route Convergence Time equals the minimum Route-Specific Convergence Time when benchmarking all routes in the FIB using the Route-Specific Loss-Derived Method. 🎀
It is not possible to measure First Route Convergence Time using the Loss-Derived Method. 🙈
Measurement Units:
seconds (and fractions)
See Also:
Rate-Derived Method, Route-Specific Loss-Derived Method, Convergence Event Instant, First Route Convergence Instant
3.6.3. Route-Specific Convergence Time 🌈
Definition:
The amount of time it takes for Route Convergence to be completed for a specific route, as calculated from the amount of Impaired Packets (Section 3.8.1) during convergence for a single route entry. 🧁
Discussion:
Route-Specific Convergence Time can only be measured using the Route-Specific Loss-Derived 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 Impaired Packet count observed on the Preferred Egress Interface and the Next-Best Egress Interface. When benchmarking Route-Specific Convergence Time, Connectivity Packet Loss is measured, and Equation 4 is applied for each measured route. The calculation is equal to Equation 8 in Section 3.6.5. 🧠
Route-Specific Convergence Time =
Connectivity Packet Loss for specific route / Offered Load per route
Equation 4If the applied Convergence Event does not cause instantaneous traffic loss for all routes at the Convergence Event Instant, then the Tester SHOULD collect timestamps of the Traffic Start Instant and of the Convergence Event Instant, and the Tester SHOULD observe Convergence Packet Loss separately on the Next-Best Egress Interface. When benchmarking Route-Specific Convergence Time, Convergence Packet Loss is measured, and Equation 5 is applied for each measured route. 🌊
Route-Specific Convergence Time =
Convergence Packet Loss for specific route / Offered Load per route
- (Convergence Event Instant - Traffic Start Instant)
Equation 5The Route-Specific 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 the route entry or entries. Since multiple Route-Specific Convergence Times can be measured, it is possible to have an array of results. 🌺 The format for reporting Route-Specific Convergence Time is provided in [Po11m]. 📝
Measurement Units:
seconds (and fractions)
See Also:
Route-Specific Loss-Derived Method, Convergence Event, Convergence Event Instant, Convergence Packet Loss, Connectivity Packet Loss, Route Convergence 🦋✨
3.6.4. Loss-Derived Convergence Time ✨
Definition:
The average Route Convergence time for all routes in the Forwarding Information Base (FIB), calculated from the number of Impaired Packets (Section 3.8.1) seen during convergence. 🎀
Discussion:
Loss-Derived Convergence Time is measured with the Loss-Derived Method. 💅
Okay so, if the Convergence Event causes instant traffic loss for all routes at the Convergence Event Instant, you should see Connectivity Packet Loss (Section 3.7.3) ✨. Connectivity Packet Loss is the combined Impaired Packet count from the Preferred Egress Interface and the Next-Best Egress Interface. When you benchmark Loss-Derived Convergence Time, you measure Connectivity Packet Loss and apply Equation 6. 🦋
Loss-Derived Convergence Time =
Connectivity Packet Loss / Offered Load
Equation 6But if the Convergence Event does not cause instant traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD collect timestamps of the Start Traffic Instant and the Convergence Event Instant 🕐. The Tester SHOULD also observe Convergence Packet Loss (Section 3.7.2) separately on the Next-Best Egress Interface 💜. When you benchmark Loss-Derived Convergence Time in this case, you measure Convergence Packet Loss and apply Equation 7. It's giving careful bookkeeping 📝🌸
Loss-Derived Convergence Time =
Convergence Packet Loss / Offered Load
- (Convergence Event Instant - Traffic Start Instant)
Equation 7Measurement Units:
seconds (and fractions) ⏱️
See Also:
Convergence Packet Loss, Connectivity Packet Loss, Route Convergence, Loss-Derived Method 🧚
3.6.5. Route Loss of Connectivity Period 🦋
Definition:
The time duration of packet impairments for one specific route entry after a Convergence Event, until Full Convergence is complete, as observed with the Route-Specific Loss-Derived Method. 🌈
Discussion:
Generally, the Route Loss of Connectivity Period is not equal to the Route-Specific Convergence Time, bestie 🙈. If the DUT keeps forwarding traffic to the Preferred Egress Interface after the Convergence Event is applied, then the Route Loss of Connectivity Period will be smaller than the Route-Specific 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 if, as a characteristic of the Convergence Event, traffic for all routes starts dropping instantly at the Convergence Event Instant. See the discussion in [Po11m] 📖.
For the test cases described in [Po11m], the Route Loss of Connectivity Period is expected to be a single Loss Period [Ko02] 💖.
When you benchmark the Route Loss of Connectivity Period, you measure Connectivity Packet Loss for each route and apply Equation 8 to each measured route entry. The calculation is equal to Equation 4 in Section 3.6.3 🧮.
Route Loss of Connectivity Period =
Connectivity Packet Loss for specific route / Offered Load per route
Equation 8The Route Loss of Connectivity Period SHOULD be measured using the Route-Specific Loss-Derived Method 🎯.
Measurement Units:
seconds (and fractions) ⏱️
See Also:
Route-Specific Convergence Time, Route-Specific Loss-Derived Method, Connectivity Packet Loss
3.6.6. Loss-Derived Loss of Connectivity Period 🌸
Definition:
The average time duration of packet impairments for all routes following a Convergence Event, until Full Convergence is complete, as observed with the Loss-Derived Method. 💜
Discussion:
Generally, the Loss-Derived Loss of Connectivity Period is not equal to the Loss-Derived Convergence Time 🙃. If the DUT keeps forwarding traffic to the Preferred Egress Interface after the Convergence Event is applied, then the Loss-Derived Loss of Connectivity Period will be smaller than the Loss-Derived Convergence Time. This is also specifically the case after reversing a failure event. 🔁
The Loss-Derived Loss of Connectivity Period may be equal to the Loss-Derived Convergence Time if, as a characteristic of the Convergence Event, traffic for all routes starts dropping instantly at the Convergence Event Instant. See the discussion in [Po11m] 👀.
For the test cases described in [Po11m], each route's Route Loss of Connectivity Period is expected to be a single Loss Period [Ko02] ✨.
When you benchmark the Loss-Derived Loss of Connectivity Period, you measure Connectivity Packet Loss for all routes and apply Equation 9. The calculation is equal to Equation 6 in Section 3.6.4 🧁.
Loss-Derived Loss of Connectivity Period =
Connectivity Packet Loss for all routes / Offered Load
Equation 9The Loss-Derived Loss of Connectivity Period SHOULD be measured using the Loss-Derived Method 💅.
Measurement Units:
seconds (and fractions) ⏱️
See Also:
Loss-Derived Convergence Time, Loss-Derived Method, Connectivity Packet Loss
3.7. Measurement Terms 🎀
3.7.1. Convergence Event 💥
Definition:
Something happens in the network that changes the DUT's egress interface for routed packets. ⚡
Discussion:
Every test case in [Po11m] is set up so that a Convergence Event results in the DUT changing its egress interface 🙌. Local or remote triggers that cause a route calculation without changing forwarding do not count, sorry not sorry 🙅♀️.
Measurement Units:
N/A
See Also:
Convergence Event Instant
3.7.2. Convergence Packet Loss 📉
Definition:
The number of Impaired Packets (Section 3.8.1) seen on the DUT's Next-Best Egress Interface during convergence. 🦋
Discussion:
An Impaired Packet counts as a lost packet. No exceptions, no drama 💀.
Measurement Units:
number of packets 📦
See Also:
Connectivity Packet Loss
3.7.3. Connectivity Packet Loss 🌐
Definition:
The number of Impaired Packets seen on all of the DUT's egress interfaces during convergence. 🧚
Discussion:
An Impaired Packet counts as a lost packet. Connectivity Packet Loss is equal to Convergence Packet Loss if the Convergence Event causes instant traffic loss on every DUT egress interface except the Next-Best Egress Interface 🎯.
Measurement Units:
number of packets 📦
See Also:
Convergence Packet Loss
3.7.4. Packet Sampling Interval ⏳
Definition:
The interval at which the Tester (the test equipment) polls to measure arriving packets. 📡
Discussion:
At least one packet per route, for all routes matched in the Offered Load, MUST be offered to the DUT within the Packet Sampling Interval 🧃. Metrics measured at the Packet Sampling Interval MUST include Forwarding Rate and received packets 📊.
The Packet Sampling Interval can change how the convergence graph looks with the Rate-Derived Method 📈. This is especially true when implementations finish Full Convergence in less time than the Packet Sampling Interval. In that case, the Convergence Event Instant and First Route Convergence Instant may be hard to spot, and the Rate-Derived Method may give a convergence time that is larger than the actual one 😭.
Using a small Packet Sampling Interval with IPDV [De02] can make the Forwarding Rate observations jump around and can stop you from seeing the different convergence time instants properly 🌊.
The value of the Packet Sampling Interval only affects the measurement accuracy of the Rate-Derived Method 🔍. For maximum accuracy, the Packet Sampling Interval SHOULD be as small as possible, though the presence of IPDV may force a larger Packet Sampling Interval 🫶.
Measurement Units:
seconds (and fractions)
See Also:
Rate-Derived Method
3.7.5. Sustained Convergence Validation Time 🛡️
Definition:
The amount of time during which the completion of Full Convergence is maintained, with no additional Impaired Packets observed 🙌.
Discussion:
The whole point of the Sustained Convergence Validation Time is to make convergence benchmarks that are protected against Forwarding Rate fluctuations after Full Convergence is observed to be complete 💖. The RECOMMENDED Sustained Convergence Validation Time is the time it takes to send 5 consecutive packets to each destination, with a minimum of 5 seconds ⏰. The Benchmarking Methodology Working Group (BMWG) picked 5 seconds based on [Br99], which suggests waiting 2 seconds for residual frames to arrive (this is the Forwarding Delay Threshold for the last packet sent) and 5 seconds for the DUT to restabilize 🧘♀️.
Measurement Units:
seconds (and fractions)
See Also:
Full Convergence, Convergence Recovery Instant
3.7.6. Forwarding Delay Threshold 🚦
Definition:
The maximum waiting time used to tell apart packets with a super long delay from lost packets that will never arrive 🕰️.
Discussion:
A Forwarding Delay Threshold lets packets with too much Forwarding Delay count as lost, which some applications need (for example voice, video, and so on) 📞. The Forwarding Delay Threshold is a parameter of the methodology, and it MUST be reported 📝. [Br99] recommends waiting 2 seconds for residual frames to arrive.
Measurement Units:
seconds (and fractions)
See Also:
Convergence Packet Loss, Connectivity Packet Loss
3.8. Miscellaneous Terms 🌈
3.8.1. Impaired Packet 🩹
Definition:
A packet that experienced at least one of these impairments: loss, excessive Forwarding Delay, corruption, duplication, or reordering. 🌀
Discussion:
A lost packet, a packet whose Forwarding Delay goes over the Forwarding Delay Threshold, a corrupted packet, a Duplicate Packet [Po06], and an Out-of-Order Packet [Po06] are all Impaired Packets 🙋♀️.
Packet ordering is observed for each individual flow (see [Th00], Section 3) of the Offered Load 🧵.
Measurement Units:
N/A
See Also:
Forwarding Delay Threshold
4. Security Considerations 🔐😱
Benchmarking activities in this memo are limited to technology characterization using controlled stimuli in a lab environment, with dedicated address space and the constraints from the sections above 🧪. Lab only, babe!
The benchmarking network topology will be an independent test setup and MUST NOT be connected to devices that might forward the test traffic into a production network or misroute traffic to the test management network 🚨. Keep that lab separate or things get messy fast 💀.
Also, benchmarking is done on a "black-box" basis, relying only on measurements you can observe from outside the DUT/SUT 🖤.
Special capabilities SHOULD NOT exist in the DUT/SUT just for benchmarking purposes 🙅♀️. Any implications for network security coming from the DUT/SUT SHOULD be identical in the lab and in production networks 🔒. No cheating allowed, no cap 👑.
5. Acknowledgements 💖
Huge shoutout to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, Peter De Vriendt, Anuj Dewagan, Adrian Farrel, Stewart Bryant, Francis Dupont, and the Benchmarking Methodology Working Group for helping make this happen 🫶✨
6. Normative References 📚
Here are the references this doc leans on, the ones you need to actually read to get the full picture 🤓
- [Br91] Bradner, S., "Benchmarking terminology for network interconnection devices", RFC 1242, July 1991.
- [Br97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [Br99] Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.
- [Ca90] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
- [Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for 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, October 2008.
- [Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.
- [Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.
- [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 Network-layer Traffic Control Mechanisms", RFC 4689, October 2006.
- [Po11m] Poretsky, S., Imhoff, B., and K. Michielsen, "Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence", RFC 6413, November 2011.
- [Th00] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, November 2000.
Authors' Addresses 🦋
The people behind this doc, so you know who to slide into the DMs with questions 💌
Scott Poretsky
Allot Communications
300 TradeCenter
Woburn, MA 01801
USA
Phone: + 1 508 309 2179
EMail: sporetsky@allot.com
Brent Imhoff
F5 Networks
401 Elliott Avenue West
Seattle, WA 98119
USA
Phone: + 1 314 378 2571
EMail: bimhoff@planetspork.com
Kris Michielsen
Cisco Systems
6A De Kleetlaan
Diegem, BRABANT 1831
Belgium
EMail: kmichiel@cisco.com📦 where this page comes from
- ietf: rfc6412 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms