diff options
Diffstat (limited to 'doc/rfc/rfc6413.txt')
| -rw-r--r-- | doc/rfc/rfc6413.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc6413.txt b/doc/rfc/rfc6413.txt new file mode 100644 index 0000000..d056637 --- /dev/null +++ b/doc/rfc/rfc6413.txt @@ -0,0 +1,2355 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Poretsky +Request for Comments: 6413 Allot Communications +Category: Informational B. Imhoff +ISSN: 2070-1721 Juniper Networks + K. Michielsen + Cisco Systems + November 2011 + + +Benchmarking Methodology for Link-State IGP Data-Plane Route Convergence + +Abstract + + This document describes the methodology for benchmarking Link-State + Interior Gateway Protocol (IGP) Route Convergence. The methodology + is to be used for benchmarking IGP convergence time through + externally observable (black-box) data-plane measurements. The + methodology can be applied to any link-state IGP, such as IS-IS and + OSPF. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6413. + +Copyright Notice + + Copyright (c) 2011 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + + + +Poretsky, et al. Informational [Page 1] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + 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. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Factors for IGP Route Convergence Time . . . . . . . . . . 4 + 1.3. Use of Data Plane for IGP Route Convergence + Benchmarking . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Applicability and Scope . . . . . . . . . . . . . . . . . 6 + 2. Existing Definitions . . . . . . . . . . . . . . . . . . . . . 6 + 3. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 7 + 3.1. Test Topology for Local Changes . . . . . . . . . . . . . 7 + 3.2. Test Topology for Remote Changes . . . . . . . . . . . . . 8 + 3.3. Test Topology for Local ECMP Changes . . . . . . . . . . . 10 + 3.4. Test Topology for Remote ECMP Changes . . . . . . . . . . 11 + 3.5. Test topology for Parallel Link Changes . . . . . . . . . 11 + 4. Convergence Time and Loss of Connectivity Period . . . . . . . 12 + 4.1. Convergence Events without Instant Traffic Loss . . . . . 13 + 4.2. Loss of Connectivity (LoC) . . . . . . . . . . . . . . . . 16 + 5. Test Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. IGP Selection . . . . . . . . . . . . . . . . . . . . . . 17 + 5.2. Routing Protocol Configuration . . . . . . . . . . . . . . 17 + 5.3. IGP Topology . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.4. Timers . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.5. Interface Types . . . . . . . . . . . . . . . . . . . . . 18 + 5.6. Offered Load . . . . . . . . . . . . . . . . . . . . . . . 18 + 5.7. Measurement Accuracy . . . . . . . . . . . . . . . . . . . 19 + 5.8. Measurement Statistics . . . . . . . . . . . . . . . . . . 20 + 5.9. Tester Capabilities . . . . . . . . . . . . . . . . . . . 20 + 6. Selection of Convergence Time Benchmark Metrics and Methods . 20 + 6.1. Loss-Derived Method . . . . . . . . . . . . . . . . . . . 21 + 6.1.1. Tester Capabilities . . . . . . . . . . . . . . . . . 21 + 6.1.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 21 + 6.1.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 21 + + + +Poretsky, et al. Informational [Page 2] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 6.2. Rate-Derived Method . . . . . . . . . . . . . . . . . . . 22 + 6.2.1. Tester Capabilities . . . . . . . . . . . . . . . . . 22 + 6.2.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 23 + 6.2.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 23 + 6.3. Route-Specific Loss-Derived Method . . . . . . . . . . . . 24 + 6.3.1. Tester Capabilities . . . . . . . . . . . . . . . . . 24 + 6.3.2. Benchmark Metrics . . . . . . . . . . . . . . . . . . 24 + 6.3.3. Measurement Accuracy . . . . . . . . . . . . . . . . . 24 + 7. Reporting Format . . . . . . . . . . . . . . . . . . . . . . . 25 + 8. Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 8.1. Interface Failure and Recovery . . . . . . . . . . . . . . 27 + 8.1.1. Convergence Due to Local Interface Failure and + Recovery . . . . . . . . . . . . . . . . . . . . . . . 27 + 8.1.2. Convergence Due to Remote Interface Failure and + Recovery . . . . . . . . . . . . . . . . . . . . . . . 28 + 8.1.3. Convergence Due to ECMP Member Local Interface + Failure and Recovery . . . . . . . . . . . . . . . . . 30 + 8.1.4. Convergence Due to ECMP Member Remote Interface + Failure and Recovery . . . . . . . . . . . . . . . . . 31 + 8.1.5. Convergence Due to Parallel Link Interface Failure + and Recovery . . . . . . . . . . . . . . . . . . . . . 32 + 8.2. Other Failures and Recoveries . . . . . . . . . . . . . . 33 + 8.2.1. Convergence Due to Layer 2 Session Loss and + Recovery . . . . . . . . . . . . . . . . . . . . . . . 33 + 8.2.2. Convergence Due to Loss and Recovery of IGP + Adjacency . . . . . . . . . . . . . . . . . . . . . . 34 + 8.2.3. Convergence Due to Route Withdrawal and + Re-Advertisement . . . . . . . . . . . . . . . . . . . 35 + 8.3. Administrative Changes . . . . . . . . . . . . . . . . . . 37 + 8.3.1. Convergence Due to Local Interface Administrative + Changes . . . . . . . . . . . . . . . . . . . . . . . 37 + 8.3.2. Convergence Due to Cost Change . . . . . . . . . . . . 38 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 + 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 3] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +1. Introduction + +1.1. Motivation + + Convergence time is a critical performance parameter. Service + Providers use IGP convergence time as a key metric of router design + and architecture. Fast network convergence can be optimally achieved + through deployment of fast converging routers. Customers of Service + Providers use packet loss due to Interior Gateway Protocol (IGP) + convergence as a key metric of their network service quality. IGP + route convergence is a Direct Measure of Quality (DMOQ) when + benchmarking the data plane. The fundamental basis by which network + users and operators benchmark convergence is packet loss and other + packet impairments, which are externally observable events having + direct impact on their application performance. For this reason, it + is important to develop a standard methodology for benchmarking link- + state IGP convergence time through externally observable (black-box) + data-plane measurements. All factors contributing to convergence + time are accounted for by measuring on the data plane. + +1.2. Factors for IGP Route Convergence Time + + There are four major categories of factors contributing to the + measured IGP convergence time. As discussed in [Vi02], [Ka02], + [Fi02], [Al00], [Al02], and [Fr05], these categories are Event + Detection, Shortest Path First (SPF) Processing, Link State + Advertisement (LSA) / Link State Packet (LSP) Advertisement, and + Forwarding Information Base (FIB) Update. These have numerous + components that influence the convergence time, including but not + limited to the list below: + + o Event Detection + + * Physical-Layer Failure/Recovery Indication Time + + * Layer 2 Failure/Recovery Indication Time + + * IGP Hello Dead Interval + + o SPF Processing + + * SPF Delay Time + + * SPF Hold Time + + * SPF Execution Time + + + + + +Poretsky, et al. Informational [Page 4] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + o LSA/LSP Advertisement + + * LSA/LSP Generation Time + + * LSA/LSP Flood Packet Pacing + + * LSA/LSP Retransmission Packet Pacing + + o FIB Update + + * Tree Build Time + + * Hardware Update Time + + o Increased Forwarding Delay due to Queueing + + The contribution of each of the factors listed above will vary with + each router vendor's architecture and IGP implementation. Routers + may have a centralized forwarding architecture, in which one + forwarding table is calculated and referenced for all arriving + packets, or a distributed forwarding architecture, in which the + central forwarding table is calculated and distributed to the + interfaces for local look-up as packets arrive. The distributed + forwarding tables are typically maintained (loaded and changed) in + software. + + The variation in router architecture and implementation necessitates + the design of a convergence test that considers all of these + components contributing to convergence time and is independent of the + Device Under Test (DUT) architecture and implementation. The benefit + of designing a test for these considerations is that it enables + black-box testing in which knowledge of the routers' internal + implementation is not required. It is then possible to make valid + use of the convergence benchmarking metrics when comparing routers + from different vendors. + + Convergence performance is tightly linked to the number of tasks a + router has to deal with. As the most important tasks are mainly + related to the control plane and the data plane, the more the DUT is + stressed as in a live production environment, the closer performance + measurement results match the ones that would be observed in a live + production environment. + +1.3. Use of Data Plane for IGP Route Convergence Benchmarking + + Customers of Service Providers use packet loss and other packet + impairments as metrics to calculate convergence time. Packet loss + and other packet impairments are externally observable events having + + + +Poretsky, et al. Informational [Page 5] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + direct impact on customers' application performance. For this + reason, it is important to develop a standard router benchmarking + methodology that is a Direct Measure of Quality (DMOQ) for measuring + IGP convergence. An additional benefit of using packet loss for + calculation of IGP Route Convergence time is that it enables black- + box tests to be designed. Data traffic can be offered to the Device + Under Test (DUT), an emulated network event can be forced to occur, + and packet loss and other impaired packets can be externally measured + to calculate the convergence time. Knowledge of the DUT architecture + and IGP implementation is not required. There is no need to rely on + the DUT to produce the test results. There is no need to build + intrusive test harnesses for the DUT. All factors contributing to + convergence time are accounted for by measuring on the data plane. + + Other work of the Benchmarking Methodology Working Group (BMWG) + focuses on characterizing single router control-plane convergence. + See [Ma05], [Ma05t], and [Ma05c]. + +1.4. Applicability and Scope + + The methodology described in this document can be applied to IPv4 and + IPv6 traffic and link-state IGPs such as IS-IS [Ca90][Ho08], OSPF + [Mo98][Co08], and others. IGP adjacencies established over any kind + of tunnel (such as Traffic Engineering tunnels) are outside the scope + of this document. Convergence time benchmarking in topologies with + IGP adjacencies that are not point-to-point will be covered in a + later document. Convergence from Bidirectional Forwarding Detection + (BFD) is outside the scope of this document. Non-Stop Forwarding + (NSF), Non-Stop Routing (NSR), Graceful Restart (GR), and any other + High Availability mechanism are outside the scope of this document. + Fast reroute mechanisms such as IP Fast-Reroute [Sh10i] or MPLS Fast- + Reroute [Pa05] are outside the scope of this document. + +2. Existing Definitions + + 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 the use of these keywords 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. + + This document uses much of the terminology defined in [Po11t]. For + any conflicting content, this document supersedes [Po11t]. This + document uses existing terminology defined in other documents issued + by the Benchmarking Methodology Working Group (BMWG). Examples + include, but are not limited to: + + + +Poretsky, et al. Informational [Page 6] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 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 4 + +3. Test Topologies + +3.1. Test Topology for Local Changes + + Figure 1 shows the test topology to measure IGP convergence time due + to local Convergence Events such as Local Interface failure and + recovery (Section 8.1.1), Layer 2 session failure and recovery + (Section 8.2.1), and IGP adjacency failure and recovery + (Section 8.2.2). This topology is also used to measure IGP + convergence time due to route withdrawal and re-advertisement + (Section 8.2.3) and to measure IGP convergence time due to route cost + change (Section 8.3.2) Convergence Events. IGP adjacencies MUST be + established between Tester and DUT: one on the Ingress Interface, one + on the Preferred Egress Interface, and one on the Next-Best Egress + Interface. For this purpose, the Tester emulates three routers (RTa, + RTb, and RTc), each establishing one adjacency with the DUT. + + ------- + | | Preferred ....... + | |------------------. RTb . + ....... Ingress | | Egress Interface ....... + . RTa .------------| DUT | + ....... Interface | | Next-Best ....... + | |------------------. RTc . + | | Egress Interface ....... + ------- + + Figure 1: IGP convergence test topology for local changes + + Figure 2 shows the test topology to measure IGP convergence time due + to local Convergence Events with a non-Equal Cost Multipath (ECMP) + Preferred Egress Interface and ECMP Next-Best Egress Interfaces + (Section 8.1.1). In this topology, the DUT is configured with each + Next-Best Egress Interface as a member of a single ECMP set. The + Preferred Egress Interface is not a member of an ECMP set. The + Tester emulates N+2 neighbor routers (N>0): one router for the + + + +Poretsky, et al. Informational [Page 7] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Ingress Interface (RTa), one router for the Preferred Egress + Interface (RTb), and N routers for the members of the ECMP set + (RTc1...RTcN). IGP adjacencies MUST be established between Tester + and DUT: one on the Ingress Interface, one on the Preferred Egress + Interface, and one on each member of the ECMP set. When the test + specifies to observe the Next-Best Egress Interface statistics, the + combined statistics for all ECMP members should be observed. + + ------- + | | Preferred ....... + | |------------------. RTb . + | | Egress Interface ....... + | | + | | ECMP Set ........ + ....... Ingress | |------------------. RTc1 . + . RTa .------------| DUT | Interface 1 ........ + ....... Interface | | . + | | . + | | . + | | ECMP Set ........ + | |------------------. RTcN . + | | Interface N ........ + ------- + + Figure 2: IGP convergence test topology for local changes with non- + ECMP to ECMP convergence + +3.2. Test Topology for Remote Changes + + Figure 3 shows the test topology to measure IGP convergence time due + to Remote Interface failure and recovery (Section 8.1.2). In this + topology, the two routers DUT1 and DUT2 are considered the System + Under Test (SUT) and SHOULD be identically configured devices of the + same model. IGP adjacencies MUST be established between Tester and + SUT, one on the Ingress Interface, one on the Preferred Egress + Interface, and one on the Next-Best Egress Interface. For this + purpose, the Tester emulates three routers (RTa, RTb, and RTc). In + this topology, a packet forwarding loop, also known as micro-loop + (see [Sh10]), may occur transiently between DUT1 and DUT2 during + convergence. + + + + + + + + + + + +Poretsky, et al. Informational [Page 8] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + -------- + | | -------- Preferred ....... + | |--| DUT2 |------------------. RTb . + ....... Ingress | | -------- Egress Interface ....... + . RTa .------------| DUT1 | + ....... Interface | | Next-Best ....... + | |----------------------------. RTc . + | | Egress Interface ....... + -------- + + Figure 3: IGP convergence test topology for remote changes + + Figure 4 shows the test topology to measure IGP convergence time due + to remote Convergence Events with a non-ECMP Preferred Egress + Interface and ECMP Next-Best Egress Interfaces (Section 8.1.2). In + this topology the two routers DUT1 and DUT2 are considered System + Under Test (SUT) and MUST be identically configured devices of the + same model. Router DUT1 is configured with the Next-Best Egress + Interface an ECMP set of interfaces. The Preferred Egress Interface + of DUT1 is not a member of an ECMP set. The Tester emulates N+2 + neighbor routers (N>0), one for the Ingress Interface (RTa), one for + DUT2 (RTb) and one for each member of the ECMP set (RTc1...RTcN). + IGP adjacencies MUST be established between Tester and SUT, one on + each interface of the SUT. For this purpose each of the N+2 routers + emulated by the Tester establishes one adjacency with the SUT. In + this topology, there is a possibility of a packet-forwarding loop + that may occur transiently between DUT1 and DUT2 during convergence + (micro-loop, see [Sh10]). When the test specifies to observe the + Next-Best Egress Interface statistics, the combined statistics for + all members of the ECMP set should be observed. + + + + + + + + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 9] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + -------- + | | -------- Preferred ....... + | |--| DUT2 |------------------. RTb . + | | -------- Egress Interface ....... + | | + | | ECMP Set ........ + ....... Ingress | |----------------------------. RTc1 . + . RTa .------------| DUT1 | Interface 1 ........ + ....... Interface | | . + | | . + | | . + | | ECMP Set ........ + | |----------------------------. RTcN . + | | Interface N ........ + -------- + + Figure 4: IGP convergence test topology for remote changes with + non-ECMP to ECMP convergence + +3.3. Test Topology for Local ECMP Changes + + Figure 5 shows the test topology to measure IGP convergence time due + to local Convergence Events of a member of an Equal Cost Multipath + (ECMP) set (Section 8.1.3). In this topology, the DUT is configured + with each egress interface as a member of a single ECMP set and the + Tester emulates N+1 next-hop routers, one for the Ingress Interface + (RTa) and one for each member of the ECMP set (RTb1...RTbN). IGP + adjacencies MUST be established between Tester and DUT, one on the + Ingress Interface and one on each member of the ECMP set. For this + purpose, each of the N+1 routers emulated by the Tester establishes + one adjacency with the DUT. When the test specifies to observe the + Next-Best Egress Interface statistics, the combined statistics for + all ECMP members except the one affected by the Convergence Event + should be observed. + + ------- + | | ECMP Set ........ + | |-------------. RTb1 . + | | Interface 1 ........ + ....... Ingress | | . + . RTa .------------| DUT | . + ....... Interface | | . + | | ECMP Set ........ + | |-------------. RTbN . + | | Interface N ........ + ------- + + Figure 5: IGP convergence test topology for local ECMP changes + + + +Poretsky, et al. Informational [Page 10] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +3.4. Test Topology for Remote ECMP Changes + + Figure 6 shows the test topology to measure IGP convergence time due + to remote Convergence Events of a member of an Equal Cost Multipath + (ECMP) set (Section 8.1.4). In this topology, the two routers DUT1 + and DUT2 are considered the System Under Test (SUT) and MUST be + identically configured devices of the same model. Router DUT1 is + configured with each egress interface as a member of a single ECMP + set, and the Tester emulates N+1 neighbor routers (N>0), one for the + Ingress Interface (RTa) and one for each member of the ECMP set + (RTb1...RTbN). IGP adjacencies MUST be established between Tester + and SUT, one on each interface of the SUT. For this purpose, each of + the N+1 routers emulated by the Tester establishes one adjacency with + the SUT (N-1 emulated routers are adjacent to DUT1 egress interfaces, + one emulated router is adjacent to DUT1 Ingress Interface, and one + emulated router is adjacent to DUT2). In this topology, there is a + possibility of a packet-forwarding loop that may occur transiently + between DUT1 and DUT2 during convergence (micro-loop, see [Sh10]). + When the test specifies to observe the Next-Best Egress Interface + statistics, the combined statistics for all ECMP members except the + one affected by the Convergence Event should be observed. + + -------- + | | ECMP Set -------- ........ + | |-------------| DUT2 |---. RTb1 . + | | Interface 1 -------- ........ + | | + | | ECMP Set ........ + ....... Ingress | |------------------------. RTb2 . + . RTa .------------| DUT1 | Interface 2 ........ + ....... Interface | | . + | | . + | | . + | | ECMP Set ........ + | |------------------------. RTbN . + | | Interface N ........ + -------- + + Figure 6: IGP convergence test topology for remote ECMP changes + +3.5. Test topology for Parallel Link Changes + + Figure 7 shows the test topology to measure IGP convergence time due + to local Convergence Events with members of a Parallel Link + (Section 8.1.5). In this topology, the DUT is configured with each + egress interface as a member of a Parallel Link and the Tester + emulates two neighbor routers, one for the Ingress Interface (RTa) + and one for the Parallel Link members (RTb). IGP adjacencies MUST be + + + +Poretsky, et al. Informational [Page 11] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + established on the Ingress Interface and on all N members of the + Parallel Link between Tester and DUT (N>0). For this purpose, the + routers emulated by the Tester establishes N+1 adjacencies with the + DUT. When the test specifies to observe the Next-Best Egress + Interface statistics, the combined statistics for all Parallel Link + members except the one affected by the Convergence Event should be + observed. + + ------- ....... + | | Parallel Link . . + | |----------------. . + | | Interface 1 . . + ....... Ingress | | . . . + . RTa .------------| DUT | . . RTb . + ....... Interface | | . . . + | | Parallel Link . . + | |----------------. . + | | Interface N . . + ------- ....... + + Figure 7: IGP convergence test topology for Parallel Link changes + +4. Convergence Time and Loss of Connectivity Period + + Two concepts will be highlighted in this section: convergence time + and loss of connectivity period. + + The Route Convergence [Po11t] time indicates the period in time + between the Convergence Event Instant [Po11t] and the instant in time + the DUT is ready to forward traffic for a specific route on its Next- + Best Egress Interface and maintains this state for the duration of + the Sustained Convergence Validation Time [Po11t]. To measure Route + Convergence time, the Convergence Event Instant and the traffic + received from the Next-Best Egress Interface need to be observed. + + The Route Loss of Connectivity Period [Po11t] indicates the time + during which traffic to a specific route is lost following a + Convergence Event until Full Convergence [Po11t] completes. This + Route Loss of Connectivity Period can consist of one or more Loss + Periods [Ko02]. For the test cases described in this document, it is + expected to have a single Loss Period. To measure the Route Loss of + Connectivity Period, the traffic received from the Preferred Egress + Interface and the traffic received from the Next-Best Egress + Interface need to be observed. + + The Route Loss of Connectivity Period is most important since that + has a direct impact on the network user's application performance. + + + + +Poretsky, et al. Informational [Page 12] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + In general, the Route Convergence time is larger than or equal to the + Route Loss of Connectivity Period. Depending on which Convergence + Event occurs and how this Convergence Event is applied, traffic for a + route may still be forwarded over the Preferred Egress Interface + after the Convergence Event Instant, before converging to the Next- + Best Egress Interface. In that case, the Route Loss of Connectivity + Period is shorter than the Route Convergence time. + + At least one condition needs to be fulfilled for Route Convergence + time to be equal to Route Loss of Connectivity Period. The condition + is that the Convergence Event causes an instantaneous traffic loss + for the measured route. A fiber cut on the Preferred Egress + Interface is an example of such a Convergence Event. + + A second condition applies to Route Convergence time measurements + based on Connectivity Packet Loss [Po11t]. This second condition is + that there is only a single Loss Period during Route Convergence. + For the test cases described in this document, the second condition + is expected to apply. + +4.1. Convergence Events without Instant Traffic Loss + + To measure convergence time benchmarks for Convergence Events caused + by a Tester, such as an IGP cost change, the Tester MAY start to + discard all traffic received from the Preferred Egress Interface at + the Convergence Event Instant, or MAY separately observe packets + received from the Preferred Egress Interface prior to the Convergence + Event Instant. This way, these Convergence Events can be treated the + same as Convergence Events that cause instantaneous traffic loss. + + To measure convergence time benchmarks without instantaneous traffic + loss (either real or induced by the Tester) at the Convergence Event + Instant, such as a reversion of a link failure Convergence Event, the + Tester SHALL only observe packet statistics on the Next-Best Egress + Interface. If using the Rate-Derived method to benchmark convergence + times for such Convergence Events, the Tester MUST collect a + timestamp at the Convergence Event Instant. If using a loss-derived + method to benchmark convergence times for such Convergence Events, + the Tester MUST measure the period in time between the Start Traffic + Instant and the Convergence Event Instant. To measure this period in + time, the Tester can collect timestamps at the Start Traffic Instant + and the Convergence Event Instant. + + The Convergence Event Instant together with the receive rate + observations on the Next-Best Egress Interface allow the derivation + of the convergence time benchmarks using the Rate-Derived Method + [Po11t]. + + + + +Poretsky, et al. Informational [Page 13] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + By observing packets on the Next-Best Egress Interface only, the + observed Impaired Packet count is the number of Impaired Packets + between Traffic Start Instant and Convergence Recovery Instant. To + measure convergence times using a loss-derived method, the Impaired + Packet count between the Convergence Event Instant and the + Convergence Recovery Instant is needed. The time between Traffic + Start Instant and Convergence Event Instant must be accounted for. + An example may clarify this. + + Figure 8 illustrates a Convergence Event without instantaneous + traffic loss for all routes. The top graph shows the Forwarding Rate + over all routes, the bottom graph shows the Forwarding Rate for a + single route Rta. Some time after the Convergence Event Instant, the + Forwarding Rate observed on the Preferred Egress Interface starts to + decrease. In the example, route Rta is the first route to experience + packet loss at time Ta. Some time later, the Forwarding Rate + observed on the Next-Best Egress Interface starts to increase. In + the example, route Rta is the first route to complete convergence at + time Ta'. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 14] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + ^ + Fwd | + Rate |------------- ............ + | \ . + | \ . + | \ . + | \ . + |.................-.-.-.-.-.-.---------------- + +----+-------+---------------+-----------------> + ^ ^ ^ ^ time + T0 CEI Ta Ta' + + ^ + Fwd | + Rate |------------- ................. + Rta | | . + | | . + |.............-.-.-.-.-.-.-.-.---------------- + +----+-------+---------------+-----------------> + ^ ^ ^ ^ time + T0 CEI Ta Ta' + + Preferred Egress Interface: --- + Next-Best Egress Interface: ... + + T0 : Start Traffic Instant + CEI : Convergence Event Instant + Ta : the time instant packet loss for route Rta starts + Ta' : the time instant packet impairment for route Rta ends + + Figure 8 + + If only packets received on the Next-Best Egress Interface are + observed, the duration of the loss period for route Rta can be + calculated from the received packets as in Equation 1. Since the + Convergence Event Instant is the start time for convergence time + measurement, the period in time between T0 and CEI needs to be + subtracted from the calculated result to become the convergence time, + as in Equation 2. + + Next-Best Egress Interface loss period + = (packets transmitted + - packets received from Next-Best Egress Interface) / tx rate + = Ta' - T0 + + Equation 1 + + + + + +Poretsky, et al. Informational [Page 15] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + convergence time + = Next-Best Egress Interface loss period - (CEI - T0) + = Ta' - CEI + + Equation 2 + +4.2. Loss of Connectivity (LoC) + + Route Loss of Connectivity Period SHOULD be measured using the Route- + Specific Loss-Derived Method. Since the start instant and end + instant of the Route Loss of Connectivity Period can be different for + each route, these cannot be accurately derived by only observing + global statistics over all routes. An example may clarify this. + + Following a Convergence Event, route Rta is the first route for which + packet impairment starts; the Route Loss of Connectivity Period for + route Rta starts at time Ta. Route Rtb is the last route for which + packet impairment starts; the Route Loss of Connectivity Period for + route Rtb starts at time Tb with Tb>Ta. + + ^ + Fwd | + Rate |-------- ----------- + | \ / + | \ / + | \ / + | \ / + | --------------- + +------------------------------------------> + ^ ^ ^ ^ time + Ta Tb Ta' Tb' + Tb'' Ta'' + + Figure 9: Example Route Loss Of Connectivity Period + + If the DUT implementation were such that route Rta would be the first + route for which traffic loss ends at time Ta' (with Ta'>Tb), and + route Rtb would be the last route for which traffic loss ends at time + Tb' (with Tb'>Ta'). By only observing global traffic statistics over + all routes, the minimum Route Loss of Connectivity Period would be + measured as Ta'-Ta. The maximum calculated Route Loss of + Connectivity Period would be Tb'-Ta. The real minimum and maximum + Route Loss of Connectivity Periods are Ta'-Ta and Tb'-Tb. + Illustrating this with the numbers Ta=0, Tb=1, Ta'=3, and Tb'=5 would + give a Loss of Connectivity Period between 3 and 5 derived from the + global traffic statistics, versus the real Loss of Connectivity + Period between 3 and 4. + + + + +Poretsky, et al. Informational [Page 16] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + If the DUT implementation were such that route Rtb would be the first + for which packet loss ends at time Tb'' and route Rta would be the + last for which packet impairment ends at time Ta'', then the minimum + and maximum Route Loss of Connectivity Periods derived by observing + only global traffic statistics would be Tb''-Ta and Ta''-Ta. The + real minimum and maximum Route Loss of Connectivity Periods are + Tb''-Tb and Ta''-Ta. Illustrating this with the numbers Ta=0, Tb=1, + Ta''=5, Tb''=3 would give a Loss of Connectivity Period between 3 and + 5 derived from the global traffic statistics, versus the real Loss of + Connectivity Period between 2 and 5. + + The two implementation variations in the above example would result + in the same derived minimum and maximum Route Loss of Connectivity + Periods when only observing the global packet statistics, while the + real Route Loss of Connectivity Periods are different. + +5. Test Considerations + +5.1. IGP Selection + + The test cases described in Section 8 can be used for link-state + IGPs, such as IS-IS or OSPF. The IGP convergence time test + methodology is identical. + +5.2. Routing Protocol Configuration + + The obtained results for IGP convergence time may vary if other + routing protocols are enabled and routes learned via those protocols + are installed. IGP convergence times SHOULD be benchmarked without + routes installed from other protocols. Any enabled IGP routing + protocol extension (such as extensions for Traffic Engineering) and + any enabled IGP routing protocol security mechanism must be reported + with the results. + +5.3. IGP Topology + + The Tester emulates a single IGP topology. The DUT establishes IGP + adjacencies with one or more of the emulated routers in this single + IGP topology emulated by the Tester. See test topology details in + Section 3. The emulated topology SHOULD only be advertised on the + DUT egress interfaces. + + The number of IGP routes and number of nodes in the topology, and the + type of topology will impact the measured IGP convergence time. To + obtain results similar to those that would be observed in an + operational network, it is RECOMMENDED that the number of installed + routes and nodes closely approximate that of the network (e.g., + thousands of routes with tens or hundreds of nodes). + + + +Poretsky, et al. Informational [Page 17] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + The number of areas (for OSPF) and levels (for IS-IS) can impact the + benchmark results. + +5.4. Timers + + There are timers that may impact the measured IGP convergence times. + The benchmark metrics MAY be measured at any fixed values for these + timers. To obtain results similar to those that would be observed in + an operational network, it is RECOMMENDED to configure the timers + with the values as configured in the operational network. + + Examples of timers that may impact measured IGP convergence time + include, but are not limited to: + + Interface failure indication + + IGP hello timer + + IGP dead-interval or hold-timer + + Link State Advertisement (LSA) or Link State Packet (LSP) + generation delay + + LSA or LSP flood packet pacing + + Route calculation delay + +5.5. Interface Types + + All test cases in this methodology document can be executed with any + interface type. The type of media may dictate which test cases may + be executed. Each interface type has a unique mechanism for + detecting link failures, and the speed at which that mechanism + operates will influence the measurement results. All interfaces MUST + be the same media and Throughput [Br91][Br99] for each test case. + All interfaces SHOULD be configured as point-to-point. + +5.6. Offered Load + + The Throughput of the device, as defined in [Br91] and benchmarked in + [Br99] at a fixed packet size, needs to be determined over the + preferred path and over the next-best path. The Offered Load SHOULD + be the minimum of the measured Throughput of the device over the + primary path and over the backup path. The packet size is selectable + and MUST be recorded. Packet size is measured in bytes and includes + the IP header and payload. + + + + + +Poretsky, et al. Informational [Page 18] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + The destination addresses for the Offered Load MUST be distributed + such that all routes or a statistically representative subset of all + routes are matched and each of these routes is offered an equal share + of the Offered Load. It is RECOMMENDED to send traffic matching all + routes, but a statistically representative subset of all routes can + be used if required. + + Splitting traffic flows across multiple paths (as with ECMP or + Parallel Link sets) is in general done by hashing on various fields + on the IP or contained headers. The hashing is typically based on + the IP source and destination addresses, the protocol ID, and higher- + layer flow-dependent fields such as TCP/UDP ports. In practice, + within a network core, the hashing is based mainly or exclusively on + the IP source and destination addresses. Knowledge of the hashing + algorithm used by the DUT is not always possible beforehand and would + violate the black-box spirit of this document. Therefore, it is + RECOMMENDED to use a randomly distributed range of source and + destination IP addresses, protocol IDs, and higher-layer flow- + dependent fields for the packets of the Offered Load (see also + [Ne07]). The content of the Offered Load MUST remain the same during + the test. It is RECOMMENDED to repeat a test multiple times with + different random ranges of the header fields such that convergence + time benchmarks are measured for different distributions of traffic + over the available paths. + + In the Remote Interface failure test cases using topologies 3, 4, and + 6, there is a possibility of a packet-forwarding loop that may occur + transiently between DUT1 and DUT2 during convergence (micro-loop, see + [Sh10]). The Time To Live (TTL) or Hop Limit value of the packets + sent by the Tester may influence the benchmark measurements since it + determines which device in the topology may send an ICMP Time + Exceeded Message for looped packets. + + The duration of the Offered Load MUST be greater than the convergence + time plus the Sustained Convergence Validation Time. + + Offered load should send a packet to each destination before sending + another packet to the same destination. It is RECOMMENDED that the + packets be transmitted in a round-robin fashion with a uniform + interpacket delay. + +5.7. Measurement Accuracy + + Since Impaired Packet count is observed to measure the Route + Convergence Time, the time between two successive packets offered to + each individual route is the highest possible accuracy of any + Impaired-Packet-based measurement. The higher the traffic rate + offered to each route, the higher the possible measurement accuracy. + + + +Poretsky, et al. Informational [Page 19] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Also see Section 6 for method-specific measurement accuracy. + +5.8. Measurement Statistics + + The benchmark measurements may vary for each trial, due to the + statistical nature of timer expirations, CPU scheduling, etc. + Evaluation of the test data must be done with an understanding of + generally accepted testing practices regarding repeatability, + variance, and statistical significance of a small number of trials. + +5.9. Tester Capabilities + + It is RECOMMENDED that the Tester used to execute each test case have + the following capabilities: + + 1. Ability to establish IGP adjacencies and advertise a single IGP + topology to one or more peers. + + 2. Ability to measure Forwarding Delay, Duplicate Packets, and Out- + of-Order Packets. + + 3. An internal time clock to control timestamping, time + measurements, and time calculations. + + 4. Ability to distinguish traffic load received on the Preferred and + Next-Best Interfaces [Po11t]. + + 5. Ability to disable or tune specific Layer 2 and Layer 3 protocol + functions on any interface(s). + + The Tester MAY be capable of making non-data-plane convergence + observations and using those observations for measurements. The + Tester MAY be capable of sending and receiving multiple traffic + Streams [Po06]. + + Also see Section 6 for method-specific capabilities. + +6. Selection of Convergence Time Benchmark Metrics and Methods + + Different convergence time benchmark methods MAY be used to measure + convergence time benchmark metrics. The Tester capabilities are + important criteria to select a specific convergence time benchmark + method. The criteria to select a specific benchmark method include, + but are not limited to: + + + + + + + +Poretsky, et al. Informational [Page 20] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Tester capabilities: Sampling Interval, number of + Stream statistics to collect + Measurement accuracy: Sampling Interval, Offered Load, + number of routes + Test specification: number of routes + DUT capabilities: Throughput, IP Packet Delay + Variation + +6.1. Loss-Derived Method + +6.1.1. Tester Capabilities + + To enable collecting statistics of 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 + sending multiple Streams, the measured traffic statistics for all + Streams MUST be added together. + + In order to verify Full Convergence completion and the Sustained + Convergence Validation Time, the Tester MUST measure Forwarding Rate + each Packet Sampling Interval. + + The total number of Impaired Packets between the start of the traffic + and the end of the Sustained Convergence Validation Time is used to + calculate the Loss-Derived Convergence Time. + +6.1.2. Benchmark Metrics + + The Loss-Derived Method can be used to measure the Loss-Derived + Convergence Time, which is the average convergence time over all + routes, and to measure the Loss-Derived Loss of Connectivity Period, + which is the average Route Loss of Connectivity Period over all + routes. + +6.1.3. Measurement Accuracy + + The actual value falls within the accuracy interval [-(number of + destinations/Offered Load), +(number of destinations/Offered Load)] + around the value as measured using the Loss-Derived Method. + + + + + + + + + + + + +Poretsky, et al. Informational [Page 21] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +6.2. Rate-Derived Method + +6.2.1. Tester Capabilities + + To enable collecting statistics of 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 + sending multiple Streams, the measured traffic statistics for all + Streams MUST be added together. + + The Tester measures Forwarding Rate each Sampling Interval. The + Packet Sampling Interval influences the observation of the different + convergence time instants. If the Packet Sampling Interval is large + compared to the time between the convergence time instants, then the + different time instants may not be easily identifiable from the + Forwarding Rate observation. The presence of IP Packet Delay + Variation (IPDV) [De02] may cause fluctuations of the Forwarding Rate + observation and can prevent correct observation of the different + convergence time instants. + + The Packet Sampling Interval MUST be larger than or equal to the time + between two consecutive packets to the same destination. For maximum + accuracy, the value for the Packet Sampling Interval SHOULD be as + small as possible, but the presence of IPDV may require the use of a + larger Packet Sampling Interval. The Packet Sampling Interval MUST + be reported. + + IPDV causes fluctuations in the number of received packets during + each Packet Sampling Interval. To account for the presence of IPDV + in determining if 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 presence of IPDV can be calculated with Equation 3. + + 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 3 + + To determine if a convergence instant has been reached, the number of + packets received in a Packet Sampling Interval is compared with the + range of expected number of packets calculated in Equation 3. + + + + +Poretsky, et al. Informational [Page 22] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +6.2.2. Benchmark Metrics + + The Rate-Derived Method SHOULD be used to measure First Route + Convergence Time and Full Convergence Time. It SHOULD NOT be used to + measure Loss of Connectivity Period (see Section 4). + +6.2.3. Measurement Accuracy + + The measurement accuracy interval of the Rate-Derived Method depends + on the metric being measured or calculated and the characteristics of + the related transition. IP Packet Delay Variation (IPDV) [De02] adds + uncertainty to the amount of packets received in a Packet Sampling + Interval, and this uncertainty adds to the measurement error. The + effect of IPDV is not accounted for in the calculation of the + accuracy intervals below. IPDV is of importance for the convergence + instants where a variation in Forwarding Rate needs to be observed. + This is applicable to the Convergence Recovery Instant for all + topologies, and for topologies with ECMP it also applies to the + Convergence Event Instant and the First Route Convergence Instant. + and for topologies with ECMP also Convergence Event Instant and First + Route Convergence Instant). + + If the Convergence Event Instant is observed on the data plane using + the Rate Derived Method, it needs to be instantaneous for all routes + (see Section 4.1). The actual value of the Convergence Event Instant + falls within the accuracy interval [-(Packet Sampling Interval + + 1/Offered Load), +0] around the value as measured using the Rate- + Derived Method. + + If the Convergence Recovery Transition is non-instantaneous for all + routes, then the actual value of the First Route Convergence Instant + falls within the accuracy interval [-(Packet Sampling Interval + time + between two consecutive packets to the same destination), +0] around + the value as measured using the Rate-Derived Method, and the actual + value of the Convergence Recovery Instant falls within the accuracy + interval [-(2 * Packet Sampling Interval), -(Packet Sampling Interval + - time between two consecutive packets to the same destination)] + around the value as measured using the Rate-Derived Method. + + The term "time between two consecutive packets to the same + destination" is added in the above accuracy intervals since packets + are sent in a particular order to all destinations in a stream, and + when part of the routes experience packet loss, it is unknown where + in the transmit cycle packets to these routes are sent. This + uncertainty adds to the error. + + + + + + +Poretsky, et al. Informational [Page 23] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + The accuracy intervals of the derived metrics First Route Convergence + Time and Rate-Derived Convergence Time are calculated from the above + convergence instants accuracy intervals. The actual value of First + Route Convergence Time falls within the accuracy interval [-(Packet + Sampling Interval + time between two consecutive packets to the same + destination), +(Packet Sampling Interval + 1/Offered Load)] around + the calculated value. The actual value of Rate-Derived Convergence + Time falls within the accuracy interval [-(2 * Packet Sampling + Interval), +(time between two consecutive packets to the same + destination + 1/Offered Load)] around the calculated value. + +6.3. Route-Specific Loss-Derived Method + +6.3.1. Tester Capabilities + + The Offered Load consists of multiple Streams. The Tester MUST + measure Impaired Packet count for each Stream separately. + + In order to verify Full Convergence completion and the Sustained + Convergence Validation Time, the Tester MUST measure Forwarding Rate + each Packet Sampling Interval. This measurement at each Packet + Sampling Interval MAY be per Stream. + + Only the total number of Impaired Packets measured per Stream at the + end of the Sustained Convergence Validation Time is used to calculate + the benchmark metrics with this method. + +6.3.2. Benchmark Metrics + + The Route-Specific Loss-Derived Method SHOULD be used to measure + Route-Specific Convergence Times. It is the RECOMMENDED method to + measure Route Loss of Connectivity Period. + + Under the conditions explained in Section 4, First Route Convergence + Time and Full Convergence Time, as benchmarked using Rate-Derived + Method, may be equal to the minimum and maximum (respectively) of the + Route-Specific Convergence Times. + +6.3.3. Measurement Accuracy + + The actual value falls within the accuracy interval [-(number of + destinations/Offered Load), +(number of destinations/Offered Load)] + around the value as measured using the Route-Specific Loss-Derived + Method. + + + + + + + +Poretsky, et al. Informational [Page 24] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +7. Reporting Format + + For each test case, it is RECOMMENDED that the reporting tables below + be completed. All time values SHOULD be reported with a sufficiently + high resolution (fractions of a second sufficient to distinguish + significant differences between measured values). + + Parameter Units + ------------------------------------- --------------------------- + Test Case test case number + Test Topology Test Topology Figure number + IGP (IS-IS, OSPF, other) + Interface Type (GigE, POS, ATM, other) + Packet Size offered to DUT bytes + Offered Load packets per second + IGP Routes Advertised to DUT number of IGP routes + Nodes in Emulated Network number of nodes + Number of Parallel or ECMP links number of links + Number of Routes Measured number of routes + Packet Sampling Interval on Tester seconds + Forwarding Delay Threshold seconds + + Timer Values configured on DUT: + Interface Failure Indication Delay seconds + IGP Hello Timer seconds + IGP Dead-Interval or Hold-Time seconds + LSA/LSP Generation Delay seconds + LSA/LSP Flood Packet Pacing seconds + LSA/LSP Retransmission Packet Pacing seconds + Route Calculation Delay seconds + + Test Details: + + Describe the IGP extensions and IGP security mechanisms that are + configured on the DUT. + + Describe how the various fields on the IP and contained headers + for the packets for the Offered Load are generated (Section 5.6). + + If the Offered Load matches a subset of routes, describe how this + subset is selected. + + Describe how the Convergence Event is applied; does it cause + instantaneous traffic loss or not? + + The table below should be completed for the initial Convergence Event + and the reversion Convergence Event. + + + + +Poretsky, et al. Informational [Page 25] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Parameter Units + ------------------------------------------- ---------------------- + Convergence Event (initial or reversion) + + Traffic Forwarding Metrics: + Total number of packets offered to DUT number of packets + Total number of packets forwarded by DUT number of packets + Connectivity Packet Loss number of packets + Convergence Packet Loss number of packets + Out-of-Order Packets number of packets + Duplicate Packets number of packets + Excessive Forwarding Delay Packets number of packets + + Convergence Benchmarks: + Rate-Derived Method: + First Route Convergence Time seconds + Full Convergence Time seconds + Loss-Derived Method: + Loss-Derived Convergence Time seconds + Route-Specific Loss-Derived Method: + Route-Specific Convergence Time[n] array of seconds + Minimum Route-Specific Convergence Time seconds + Maximum Route-Specific Convergence Time seconds + Median Route-Specific Convergence Time seconds + Average Route-Specific Convergence Time seconds + + Loss of Connectivity Benchmarks: + Loss-Derived Method: + Loss-Derived Loss of Connectivity Period seconds + Route-Specific Loss-Derived Method: + Route Loss of Connectivity Period[n] array of seconds + Minimum Route Loss of Connectivity Period seconds + Maximum Route Loss of Connectivity Period seconds + Median Route Loss of Connectivity Period seconds + Average Route Loss of Connectivity Period seconds + +8. Test Cases + + It is RECOMMENDED that all applicable test cases be performed for + best characterization of the DUT. The test cases follow a generic + procedure tailored to the specific DUT configuration and Convergence + Event [Po11t]. This generic procedure is as follows: + + 1. Establish DUT and Tester configurations and advertise an IGP + topology from Tester to DUT. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + + + +Poretsky, et al. Informational [Page 26] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 3. Verify traffic is routed correctly. Verify if traffic is + forwarded without Impaired Packets [Po06]. + + 4. Introduce Convergence Event [Po11t]. + + 5. Measure First Route Convergence Time [Po11t]. + + 6. Measure Full Convergence Time [Po11t]. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period [Po11t]. At the same time, + measure number of Impaired Packets [Po11t]. + + 9. Wait sufficient time for queues to drain. The duration of this + time period MUST be larger than or equal to the Forwarding Delay + Threshold. + + 10. Restart Offered Load. + + 11. Reverse Convergence Event. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets [Po11t]. + +8.1. Interface Failure and Recovery + +8.1.1. Convergence Due to Local Interface Failure and Recovery + + Objective: + + To obtain the IGP convergence measurements for Local Interface + failure and recovery events. The Next-Best Egress Interface can + be a single interface (Figure 1) or an ECMP set (Figure 2). The + test with ECMP topology (Figure 2) is OPTIONAL. + + + + + + +Poretsky, et al. Informational [Page 27] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figures 1 or 2. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is forwarded over Preferred Egress Interface. + + 4. Remove link on the Preferred Egress Interface of the DUT. This + is the Convergence Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times and Loss-Derived + Convergence Time. At the same time, measure number of Impaired + Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore link on the Preferred Egress Interface of the DUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + +8.1.2. Convergence Due to Remote Interface Failure and Recovery + + Objective: + + To obtain the IGP convergence measurements for Remote Interface + failure and recovery events. The Next-Best Egress Interface can + be a single interface (Figure 3) or an ECMP set (Figure 4). The + test with ECMP topology (Figure 4) is OPTIONAL. + + + + +Poretsky, et al. Informational [Page 28] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Procedure: + + 1. Advertise an IGP topology from Tester to SUT using the topology + shown in Figures 3 or 4. + + 2. Send Offered Load from Tester to SUT on Ingress Interface. + + 3. Verify traffic is forwarded over Preferred Egress Interface. + + 4. Remove link on the interface of the Tester connected to the + Preferred Egress Interface of the SUT. This is the Convergence + Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times and Loss-Derived + Convergence Time. At the same time, measure number of Impaired + Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore link on the interface of the Tester connected to the + Preferred Egress Interface of the SUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + Discussion: + + In this test case, there is a possibility of a packet-forwarding + loop that may occur transiently between DUT1 and DUT2 during + convergence (micro-loop, see [Sh10]), which may increase the + measured convergence times and loss of connectivity periods. + + + + +Poretsky, et al. Informational [Page 29] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +8.1.3. Convergence Due to ECMP Member Local Interface Failure and + Recovery + + Objective: + + To obtain the IGP convergence measurements for Local Interface + link failure and recovery events of an ECMP Member. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the test + setup shown in Figure 5. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is forwarded over the ECMP member interface of + the DUT that will be failed in the next step. + + 4. Remove link on one of the ECMP member interfaces of the DUT. + This is the Convergence Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times and Loss-Derived + Convergence Time. At the same time, measure number of Impaired + Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore link on the ECMP member interface of the DUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + + + +Poretsky, et al. Informational [Page 30] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + +8.1.4. Convergence Due to ECMP Member Remote Interface Failure and + Recovery + + Objective: + + To obtain the IGP convergence measurements for Remote Interface + link failure and recovery events for an ECMP Member. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the test + setup shown in Figure 6. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is forwarded over the ECMP member interface of + the DUT that will be failed in the next step. + + 4. Remove link on the interface of the Tester to R2. This is the + Convergence Event Trigger. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times and Loss-Derived + Convergence Time. At the same time, measure number of Impaired + Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore link on the interface of the Tester to R2. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + + + +Poretsky, et al. Informational [Page 31] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Discussion: + + In this test case, there is a possibility of a packet-forwarding + loop that may occur temporarily between DUT1 and DUT2 during + convergence (micro-loop, see [Sh10]), which may increase the + measured convergence times and loss of connectivity periods. + +8.1.5. Convergence Due to Parallel Link Interface Failure and Recovery + + Objective: + + To obtain the IGP convergence measurements for local link failure + and recovery events for a member of a parallel link. The links + can be used for data load-balancing + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the test + setup shown in Figure 7. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is forwarded over the parallel link member that + will be failed in the next step. + + 4. Remove link on one of the parallel link member interfaces of the + DUT. This is the Convergence Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times and Loss-Derived + Convergence Time. At the same time, measure number of Impaired + Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore link on the Parallel Link member interface of the DUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + + + +Poretsky, et al. Informational [Page 32] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + +8.2. Other Failures and Recoveries + +8.2.1. Convergence Due to Layer 2 Session Loss and Recovery + + Objective: + + To obtain the IGP convergence measurements for a local Layer 2 + loss and recovery. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figure 1. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is routed over Preferred Egress Interface. + + 4. Remove Layer 2 session from Preferred Egress Interface of the + DUT. This is the Convergence Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore Layer 2 session on Preferred Egress Interface of the + DUT. + + 12. Measure First Route Convergence Time. + + + + +Poretsky, et al. Informational [Page 33] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + Discussion: + + When removing the Layer 2 session, the physical layer must stay + up. Configure IGP timers such that the IGP adjacency does not + time out before Layer 2 failure is detected. + + To measure convergence time, traffic SHOULD start dropping on the + Preferred Egress Interface on the instant the Layer 2 session is + removed. Alternatively, the Tester SHOULD record the time the + instant Layer 2 session is removed, and traffic loss SHOULD only + be measured on the Next-Best Egress Interface. For loss-derived + benchmarks, the time of the Start Traffic Instant SHOULD be + recorded as well. See Section 4.1. + +8.2.2. Convergence Due to Loss and Recovery of IGP Adjacency + + Objective: + + To obtain the IGP convergence measurements for loss and recovery + of an IGP Adjacency. The IGP adjacency is removed on the Tester + by disabling processing of IGP routing protocol packets on the + Tester. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figure 1. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is routed over Preferred Egress Interface. + + 4. Remove IGP adjacency from the Preferred Egress Interface while + the Layer 2 session MUST be maintained. This is the Convergence + Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + + +Poretsky, et al. Informational [Page 34] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Restore IGP session on Preferred Egress Interface of the DUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + Discussion: + + Configure Layer 2 such that Layer 2 does not time out before IGP + adjacency failure is detected. + + To measure convergence time, traffic SHOULD start dropping on the + Preferred Egress Interface on the instant the IGP adjacency is + removed. Alternatively, the Tester SHOULD record the time the + instant the IGP adjacency is removed and traffic loss SHOULD only + be measured on the Next-Best Egress Interface. For loss-derived + benchmarks, the time of the Start Traffic Instant SHOULD be + recorded as well. See Section 4.1. + +8.2.3. Convergence Due to Route Withdrawal and Re-Advertisement + + Objective: + + To obtain the IGP convergence measurements for route withdrawal + and re-advertisement. + + + + + + + + +Poretsky, et al. Informational [Page 35] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figure 1. The routes that will be withdrawn MUST be a + set of leaf routes advertised by at least two nodes in the + emulated topology. The topology SHOULD be such that before the + withdrawal the DUT prefers the leaf routes advertised by a node + "nodeA" via the Preferred Egress Interface, and after the + withdrawal the DUT prefers the leaf routes advertised by a node + "nodeB" via the Next-Best Egress Interface. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is routed over Preferred Egress Interface. + + 4. The Tester withdraws the set of IGP leaf routes from nodeA. + This is the Convergence Event. The withdrawal update message + SHOULD be a single unfragmented packet. If the routes cannot be + withdrawn by a single packet, the messages SHOULD be sent using + the same pacing characteristics as the DUT. The Tester MAY + record the time it sends the withdrawal message(s). + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Re-advertise the set of withdrawn IGP leaf routes from nodeA + emulated by the Tester. The update message SHOULD be a single + unfragmented packet. If the routes cannot be advertised by a + single packet, the messages SHOULD be sent using the same pacing + characteristics as the DUT. The Tester MAY record the time it + sends the update message(s). + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + + + +Poretsky, et al. Informational [Page 36] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + Discussion: + + To measure convergence time, traffic SHOULD start dropping on the + Preferred Egress Interface on the instant the routes are withdrawn + by the Tester. Alternatively, the Tester SHOULD record the time + the instant the routes are withdrawn, and traffic loss SHOULD only + be measured on the Next-Best Egress Interface. For loss-derived + benchmarks, the time of the Start Traffic Instant SHOULD be + recorded as well. See Section 4.1. + +8.3. Administrative Changes + +8.3.1. Convergence Due to Local Interface Administrative Changes + + Objective: + + To obtain the IGP convergence measurements for administratively + disabling and enabling a Local Interface. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figure 1. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is routed over Preferred Egress Interface. + + 4. Administratively disable the Preferred Egress Interface of the + DUT. This is the Convergence Event. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + + +Poretsky, et al. Informational [Page 37] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. Administratively enable the Preferred Egress Interface of the + DUT. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + +8.3.2. Convergence Due to Cost Change + + Objective: + + To obtain the IGP convergence measurements for route cost change. + + Procedure: + + 1. Advertise an IGP topology from Tester to DUT using the topology + shown in Figure 1. + + 2. Send Offered Load from Tester to DUT on Ingress Interface. + + 3. Verify traffic is routed over Preferred Egress Interface. + + 4. The Tester, emulating the neighbor node, increases the cost for + all IGP routes at the Preferred Egress Interface of the DUT so + that the Next-Best Egress Interface becomes the preferred path. + The update message advertising the higher cost MUST be a single + unfragmented packet. This is the Convergence Event. The Tester + MAY record the time it sends the update message advertising the + higher cost on the Preferred Egress Interface. + + 5. Measure First Route Convergence Time. + + 6. Measure Full Convergence Time. + + 7. Stop Offered Load. + + + + + +Poretsky, et al. Informational [Page 38] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + 8. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + 9. Wait sufficient time for queues to drain. + + 10. Restart Offered Load. + + 11. The Tester, emulating the neighbor node, decreases the cost for + all IGP routes at the Preferred Egress Interface of the DUT so + that the Preferred Egress Interface becomes the preferred path. + The update message advertising the lower cost MUST be a single + unfragmented packet. + + 12. Measure First Route Convergence Time. + + 13. Measure Full Convergence Time. + + 14. Stop Offered Load. + + 15. Measure Route-Specific Convergence Times, Loss-Derived + Convergence Time, Route Loss of Connectivity Periods, and Loss- + Derived Loss of Connectivity Period. At the same time, measure + number of Impaired Packets. + + Discussion: + + To measure convergence time, traffic SHOULD start dropping on the + Preferred Egress Interface on the instant the cost is changed by + the Tester. Alternatively, the Tester SHOULD record the time the + instant the cost is changed, and traffic loss SHOULD only be + measured on the Next-Best Egress Interface. For loss-derived + benchmarks, the time of the Start Traffic Instant SHOULD be + recorded as well. See Section 4.1. + +9. Security Considerations + + Benchmarking activities as described in this memo are limited to + technology characterization using controlled stimuli in a laboratory + environment, with dedicated address space and the constraints + specified in the sections above. + + The benchmarking network topology will be an independent test setup + and MUST NOT be connected to devices that may forward the test + traffic into a production network or misroute traffic to the test + management network. + + + + +Poretsky, et al. Informational [Page 39] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + Further, benchmarking is performed on a "black-box" basis, relying + solely on measurements observable external to the DUT/SUT. + + Special capabilities SHOULD NOT exist in the DUT/SUT specifically for + benchmarking purposes. Any implications for network security arising + from the DUT/SUT SHOULD be identical in the lab and in production + networks. + +10. Acknowledgements + + Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward, + Peter De Vriendt, Anuj Dewagan, Julien Meuric, Adrian Farrel, Stewart + Bryant, and the Benchmarking Methodology Working Group for their + contributions to this work. + +11. References + +11.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 + 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. + + [Ma05] Manral, V., White, R., and A. Shaikh, "Benchmarking Basic + OSPF Single Router Control Plane Convergence", RFC 4061, + April 2005. + + + + +Poretsky, et al. Informational [Page 40] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + [Ma05c] Manral, V., White, R., and A. Shaikh, "Considerations When + Using Basic OSPF Convergence Benchmarks", RFC 4063, + April 2005. + + [Ma05t] Manral, V., White, R., and A. Shaikh, "OSPF Benchmarking + Terminology and Concepts", RFC 4062, April 2005. + + [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. + + [Ne07] Newman, D. and T. Player, "Hash and Stuffing: Overlooked + Factors in Network Device Benchmarking", RFC 4814, + March 2007. + + [Pa05] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions + to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. + + [Po06] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, + "Terminology for Benchmarking Network-layer Traffic Control + Mechanisms", RFC 4689, October 2006. + + [Po11t] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology + for Benchmarking Link-State IGP Data-Plane Route + Convergence", RFC 6412, November 2011. + + [Sh10] Shand, M. and S. Bryant, "A Framework for Loop-Free + Convergence", RFC 5715, January 2010. + + [Sh10i] Shand, M. and S. Bryant, "IP Fast Reroute Framework", + RFC 5714, January 2010. + + [Th00] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and + Multicast Next-Hop Selection", RFC 2991, November 2000. + +11.2. Informative References + + [Al00] Alaettinoglu, C., Jacobson, V., and H. Yu, "Towards + Millisecond IGP Convergence", NANOG 20, October 2000. + + [Al02] Alaettinoglu, C. and S. Casner, "ISIS Routing on the Qwest + Backbone: a Recipe for Subsecond ISIS Convergence", + NANOG 24, February 2002. + + [Fi02] Filsfils, C., "Tutorial: Deploying Tight-SLA Services on an + Internet Backbone: ISIS Fast Convergence and Differentiated + Services Design", NANOG 25, June 2002. + + + +Poretsky, et al. Informational [Page 41] + +RFC 6413 IGP Convergence Benchmark Methodology November 2011 + + + [Fr05] Francois, P., Filsfils, C., Evans, J., and O. Bonaventure, + "Achieving SubSecond IGP Convergence in Large IP Networks", + ACM SIGCOMM Computer Communication Review v.35 n.3, + July 2005. + + [Ka02] Katz, D., "Why are we scared of SPF? IGP Scaling and + Stability", NANOG 25, June 2002. + + [Vi02] Villamizar, C., "Convergence and Restoration Techniques for + ISP Interior Routing", NANOG 25, June 2002. + +Authors' Addresses + + Scott Poretsky + Allot Communications + 300 TradeCenter + Woburn, MA 01801 + 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 + + + Kris Michielsen + Cisco Systems + 6A De Kleetlaan + Diegem, BRABANT 1831 + Belgium + + EMail: kmichiel@cisco.com + + + + + + + + + + + +Poretsky, et al. Informational [Page 42] + |