<pre>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 <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6413">http://www.rfc-editor.org/info/rfc6413</a>.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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 <a href="#section-4">Section 4</a>.e of



<span class="grey">Poretsky, et al.              Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.1">1.1</a>.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-4">4</a>
     <a href="#section-1.2">1.2</a>.  Factors for IGP Route Convergence Time . . . . . . . . . .  <a href="#page-4">4</a>
     1.3.  Use of Data Plane for IGP Route Convergence
           Benchmarking . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
     <a href="#section-1.4">1.4</a>.  Applicability and Scope  . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
   <a href="#section-2">2</a>.  Existing Definitions . . . . . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
   <a href="#section-3">3</a>.  Test Topologies  . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-3.1">3.1</a>.  Test Topology for Local Changes  . . . . . . . . . . . . .  <a href="#page-7">7</a>
     <a href="#section-3.2">3.2</a>.  Test Topology for Remote Changes . . . . . . . . . . . . .  <a href="#page-8">8</a>
     <a href="#section-3.3">3.3</a>.  Test Topology for Local ECMP Changes . . . . . . . . . . . <a href="#page-10">10</a>
     <a href="#section-3.4">3.4</a>.  Test Topology for Remote ECMP Changes  . . . . . . . . . . <a href="#page-11">11</a>
     <a href="#section-3.5">3.5</a>.  Test topology for Parallel Link Changes  . . . . . . . . . <a href="#page-11">11</a>
   <a href="#section-4">4</a>.  Convergence Time and Loss of Connectivity Period . . . . . . . <a href="#page-12">12</a>
     <a href="#section-4.1">4.1</a>.  Convergence Events without Instant Traffic Loss  . . . . . <a href="#page-13">13</a>
     <a href="#section-4.2">4.2</a>.  Loss of Connectivity (LoC) . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
   <a href="#section-5">5</a>.  Test Considerations  . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
     <a href="#section-5.1">5.1</a>.  IGP Selection  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
     <a href="#section-5.2">5.2</a>.  Routing Protocol Configuration . . . . . . . . . . . . . . <a href="#page-17">17</a>
     <a href="#section-5.3">5.3</a>.  IGP Topology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
     <a href="#section-5.4">5.4</a>.  Timers . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-5.5">5.5</a>.  Interface Types  . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-5.6">5.6</a>.  Offered Load . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
     <a href="#section-5.7">5.7</a>.  Measurement Accuracy . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
     <a href="#section-5.8">5.8</a>.  Measurement Statistics . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
     <a href="#section-5.9">5.9</a>.  Tester Capabilities  . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
   6.  Selection of Convergence Time Benchmark Metrics and Methods  . 20
     <a href="#section-6.1">6.1</a>.  Loss-Derived Method  . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-6.1.1">6.1.1</a>.  Tester Capabilities  . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-6.1.2">6.1.2</a>.  Benchmark Metrics  . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
       <a href="#section-6.1.3">6.1.3</a>.  Measurement Accuracy . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>



<span class="grey">Poretsky, et al.              Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


     <a href="#section-6.2">6.2</a>.  Rate-Derived Method  . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
       <a href="#section-6.2.1">6.2.1</a>.  Tester Capabilities  . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
       <a href="#section-6.2.2">6.2.2</a>.  Benchmark Metrics  . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
       <a href="#section-6.2.3">6.2.3</a>.  Measurement Accuracy . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
     <a href="#section-6.3">6.3</a>.  Route-Specific Loss-Derived Method . . . . . . . . . . . . <a href="#page-24">24</a>
       <a href="#section-6.3.1">6.3.1</a>.  Tester Capabilities  . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
       <a href="#section-6.3.2">6.3.2</a>.  Benchmark Metrics  . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
       <a href="#section-6.3.3">6.3.3</a>.  Measurement Accuracy . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
   <a href="#section-7">7</a>.  Reporting Format . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-25">25</a>
   <a href="#section-8">8</a>.  Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
     <a href="#section-8.1">8.1</a>.  Interface Failure and Recovery . . . . . . . . . . . . . . <a href="#page-27">27</a>
       8.1.1.  Convergence Due to Local Interface Failure and
               Recovery . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-27">27</a>
       8.1.2.  Convergence Due to Remote Interface Failure and
               Recovery . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
       8.1.3.  Convergence Due to ECMP Member Local Interface
               Failure and Recovery . . . . . . . . . . . . . . . . . <a href="#page-30">30</a>
       8.1.4.  Convergence Due to ECMP Member Remote Interface
               Failure and Recovery . . . . . . . . . . . . . . . . . <a href="#page-31">31</a>
       8.1.5.  Convergence Due to Parallel Link Interface Failure
               and Recovery . . . . . . . . . . . . . . . . . . . . . <a href="#page-32">32</a>
     <a href="#section-8.2">8.2</a>.  Other Failures and Recoveries  . . . . . . . . . . . . . . <a href="#page-33">33</a>
       8.2.1.  Convergence Due to Layer 2 Session Loss and
               Recovery . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
       8.2.2.  Convergence Due to Loss and Recovery of IGP
               Adjacency  . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
       8.2.3.  Convergence Due to Route Withdrawal and
               Re-Advertisement . . . . . . . . . . . . . . . . . . . <a href="#page-35">35</a>
     <a href="#section-8.3">8.3</a>.  Administrative Changes . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
       8.3.1.  Convergence Due to Local Interface Administrative
               Changes  . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-37">37</a>
       <a href="#section-8.3.2">8.3.2</a>.  Convergence Due to Cost Change . . . . . . . . . . . . <a href="#page-38">38</a>
   <a href="#section-9">9</a>.  Security Considerations  . . . . . . . . . . . . . . . . . . . <a href="#page-39">39</a>
   <a href="#section-10">10</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
   <a href="#section-11">11</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
     <a href="#section-11.1">11.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
     <a href="#section-11.2">11.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-41">41</a>














<span class="grey">Poretsky, et al.              Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Motivation</span>

   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.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Factors for IGP Route Convergence Time</span>

   There are four major categories of factors contributing to the
   measured IGP convergence time.  As discussed in [<a href="#ref-Vi02" title="&quot;Convergence and Restoration Techniques for ISP Interior Routing&quot;">Vi02</a>], [<a href="#ref-Ka02" title="&quot;Why are we scared of SPF? IGP Scaling and Stability&quot;">Ka02</a>],
   [<a href="#ref-Fi02" title="&quot;Tutorial: Deploying Tight-SLA Services on an Internet Backbone: ISIS Fast Convergence and Differentiated Services Design&quot;">Fi02</a>], [<a href="#ref-Al00" title="&quot;Towards Millisecond IGP Convergence&quot;">Al00</a>], [<a href="#ref-Al02" title="&quot;ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence&quot;">Al02</a>], and [<a href="#ref-Fr05" title="&quot;Achieving SubSecond IGP Convergence in Large IP Networks&quot;">Fr05</a>], 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





<span class="grey">Poretsky, et al.              Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>.  Use of Data Plane for IGP Route Convergence Benchmarking</span>

   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



<span class="grey">Poretsky, et al.              Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 [<a href="#ref-Ma05" title="&quot;Benchmarking Basic OSPF Single Router Control Plane Convergence&quot;">Ma05</a>], [<a href="#ref-Ma05t" title="&quot;OSPF Benchmarking Terminology and Concepts&quot;">Ma05t</a>], and [<a href="#ref-Ma05c" title="&quot;Considerations When Using Basic OSPF Convergence Benchmarks&quot;">Ma05c</a>].

<span class="h3"><a class="selflink" id="section-1.4" href="#section-1.4">1.4</a>.  Applicability and Scope</span>

   The methodology described in this document can be applied to IPv4 and
   IPv6 traffic and link-state IGPs such as IS-IS [<a href="#ref-Ca90" title="&quot;Use of OSI IS-IS for routing in TCP/IP and dual environments&quot;">Ca90</a>][Ho08], OSPF
   [<a href="#ref-Mo98" title="&quot;OSPF Version 2&quot;">Mo98</a>][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 [<a href="#ref-Sh10i" title="&quot;IP Fast Reroute Framework&quot;">Sh10i</a>] or MPLS Fast-
   Reroute [<a href="#ref-Pa05" title="&quot;Fast Reroute Extensions to RSVP-TE for LSP Tunnels&quot;">Pa05</a>] are outside the scope of this document.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Existing Definitions</span>

   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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
   [<a href="#ref-Br97" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">Br97</a>].  <a href="./rfc2119">RFC 2119</a> 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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  For
   any conflicting content, this document supersedes [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  This
   document uses existing terminology defined in other documents issued
   by the Benchmarking Methodology Working Group (BMWG).  Examples
   include, but are not limited to:



<span class="grey">Poretsky, et al.              Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


         Throughput                         [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>], Section 3.17
         Offered Load                       [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.5.2
         Forwarding Rate                    [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.6.1
         Device Under Test (DUT)            [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.1.1
         System Under Test (SUT)            [<a href="#ref-Ma98" title="&quot;Benchmarking Terminology for LAN Switching Devices&quot;">Ma98</a>], Section 3.1.2
         Out-of-Order Packet                [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.4
         Duplicate Packet                   [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.5
         Stream                             [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.3.2
         Forwarding Delay                   [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], Section 3.2.4
         IP Packet Delay Variation (IPDV)   [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>], Section 1.2
         Loss Period                        [<a href="#ref-Ko02" title="&quot;One-way Loss Pattern Sample Metrics&quot;">Ko02</a>], Section 4

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Test Topologies</span>

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Test Topology for Local Changes</span>

   Figure 1 shows the test topology to measure IGP convergence time due
   to local Convergence Events such as Local Interface failure and
   recovery (<a href="#section-8.1.1">Section 8.1.1</a>), Layer 2 session failure and recovery
   (<a href="#section-8.2.1">Section 8.2.1</a>), and IGP adjacency failure and recovery
   (<a href="#section-8.2.2">Section 8.2.2</a>).  This topology is also used to measure IGP
   convergence time due to route withdrawal and re-advertisement
   (<a href="#section-8.2.3">Section 8.2.3</a>) and to measure IGP convergence time due to route cost
   change (<a href="#section-8.3.2">Section 8.3.2</a>) 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
   (<a href="#section-8.1.1">Section 8.1.1</a>).  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&gt;0): one router for the



<span class="grey">Poretsky, et al.              Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Test Topology for Remote Changes</span>

   Figure 3 shows the test topology to measure IGP convergence time due
   to Remote Interface failure and recovery (<a href="#section-8.1.2">Section 8.1.2</a>).  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 [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]), may occur transiently between DUT1 and DUT2 during
   convergence.











<span class="grey">Poretsky, et al.              Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


                          --------
                          |      |  -------- 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 (<a href="#section-8.1.2">Section 8.1.2</a>).  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&gt;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 [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]).  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.





















<span class="grey">Poretsky, et al.              Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


                         --------
                         |      |  -------- 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

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Test Topology for Local ECMP Changes</span>

   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 (<a href="#section-8.1.3">Section 8.1.3</a>).  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



<span class="grey">Poretsky, et al.              Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Test Topology for Remote ECMP Changes</span>

   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 (<a href="#section-8.1.4">Section 8.1.4</a>).  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&gt;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 [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]).
   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

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Test topology for Parallel Link Changes</span>

   Figure 7 shows the test topology to measure IGP convergence time due
   to local Convergence Events with members of a Parallel Link
   (<a href="#section-8.1.5">Section 8.1.5</a>).  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



<span class="grey">Poretsky, et al.              Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   established on the Ingress Interface and on all N members of the
   Parallel Link between Tester and DUT (N&gt;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

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Convergence Time and Loss of Connectivity Period</span>

   Two concepts will be highlighted in this section: convergence time
   and loss of connectivity period.

   The Route Convergence [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>] time indicates the period in time
   between the Convergence Event Instant [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>] 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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>] indicates the time
   during which traffic to a specific route is lost following a
   Convergence Event until Full Convergence [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>] completes.  This
   Route Loss of Connectivity Period can consist of one or more Loss
   Periods [<a href="#ref-Ko02" title="&quot;One-way Loss Pattern Sample Metrics&quot;">Ko02</a>].  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.




<span class="grey">Poretsky, et al.              Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  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.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Convergence Events without Instant Traffic Loss</span>

   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
   [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].




<span class="grey">Poretsky, et al.              Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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'.
































<span class="grey">Poretsky, et al.              Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


           ^
      Fwd  |
      Rate |-------------                    ............
           |             \                  .
           |              \                .
           |               \              .
           |                \            .
           |.................-.-.-.-.-.-.----------------
           +----+-------+---------------+-----------------&gt;
           ^    ^       ^               ^             time
          T0   CEI      Ta              Ta'

           ^
      Fwd  |
      Rate |-------------               .................
      Rta  |            |               .
           |            |               .
           |.............-.-.-.-.-.-.-.-.----------------
           +----+-------+---------------+-----------------&gt;
           ^    ^       ^               ^             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





<span class="grey">Poretsky, et al.              Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


         convergence time
             = Next-Best Egress Interface loss period - (CEI - T0)
             = Ta' - CEI

                                Equation 2

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Loss of Connectivity (LoC)</span>

   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&gt;Ta.

                  ^
             Fwd  |
             Rate |--------                       -----------
                  |        \                     /
                  |         \                   /
                  |          \                 /
                  |           \               /
                  |            ---------------
                  +------------------------------------------&gt;
                           ^   ^             ^    ^      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'&gt;Tb), and
   route Rtb would be the last route for which traffic loss ends at time
   Tb' (with Tb'&gt;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.




<span class="grey">Poretsky, et al.              Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Test Considerations</span>

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  IGP Selection</span>

   The test cases described in <a href="#section-8">Section 8</a> can be used for link-state
   IGPs, such as IS-IS or OSPF.  The IGP convergence time test
   methodology is identical.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Routing Protocol Configuration</span>

   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.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  IGP Topology</span>

   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
   <a href="#section-3">Section 3</a>.  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).



<span class="grey">Poretsky, et al.              Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   The number of areas (for OSPF) and levels (for IS-IS) can impact the
   benchmark results.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Timers</span>

   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

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Interface Types</span>

   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 [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>][Br99] for each test case.
   All interfaces SHOULD be configured as point-to-point.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Offered Load</span>

   The Throughput of the device, as defined in [<a href="#ref-Br91" title="&quot;Benchmarking terminology for network interconnection devices&quot;">Br91</a>] and benchmarked in
   [<a href="#ref-Br99" title="&quot;Benchmarking Methodology for Network Interconnect Devices&quot;">Br99</a>] 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.





<span class="grey">Poretsky, et al.              Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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
   [<a href="#ref-Ne07" title="&quot;Hash and Stuffing: Overlooked Factors in Network Device Benchmarking&quot;">Ne07</a>]).  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
   [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]).  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.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Measurement Accuracy</span>

   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.



<span class="grey">Poretsky, et al.              Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   Also see <a href="#section-6">Section 6</a> for method-specific measurement accuracy.

<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>.  Measurement Statistics</span>

   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.

<span class="h3"><a class="selflink" id="section-5.9" href="#section-5.9">5.9</a>.  Tester Capabilities</span>

   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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

   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 [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>].

   Also see <a href="#section-6">Section 6</a> for method-specific capabilities.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Selection of Convergence Time Benchmark Metrics and Methods</span>

   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:







<span class="grey">Poretsky, et al.              Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Loss-Derived Method</span>

<span class="h4"><a class="selflink" id="section-6.1.1" href="#section-6.1.1">6.1.1</a>.  Tester Capabilities</span>

   To enable collecting statistics of Out-of-Order Packets per flow (see
   [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>], Section 3), the Offered Load SHOULD consist of multiple
   Streams [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], 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.

<span class="h4"><a class="selflink" id="section-6.1.2" href="#section-6.1.2">6.1.2</a>.  Benchmark Metrics</span>

   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.

<span class="h4"><a class="selflink" id="section-6.1.3" href="#section-6.1.3">6.1.3</a>.  Measurement Accuracy</span>

   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.












<span class="grey">Poretsky, et al.              Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Rate-Derived Method</span>

<span class="h4"><a class="selflink" id="section-6.2.1" href="#section-6.2.1">6.2.1</a>.  Tester Capabilities</span>

   To enable collecting statistics of Out-of-Order Packets per flow (see
   [<a href="#ref-Th00" title="&quot;Multipath Issues in Unicast and Multicast Next-Hop Selection&quot;">Th00</a>], Section 3), the Offered Load SHOULD consist of multiple
   Streams [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>], 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) [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>] 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.




<span class="grey">Poretsky, et al.              Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h4"><a class="selflink" id="section-6.2.2" href="#section-6.2.2">6.2.2</a>.  Benchmark Metrics</span>

   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 <a href="#section-4">Section 4</a>).

<span class="h4"><a class="selflink" id="section-6.2.3" href="#section-6.2.3">6.2.3</a>.  Measurement Accuracy</span>

   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) [<a href="#ref-De02" title="&quot;IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)&quot;">De02</a>] 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 <a href="#section-4.1">Section 4.1</a>).  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.






<span class="grey">Poretsky, et al.              Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Route-Specific Loss-Derived Method</span>

<span class="h4"><a class="selflink" id="section-6.3.1" href="#section-6.3.1">6.3.1</a>.  Tester Capabilities</span>

   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.

<span class="h4"><a class="selflink" id="section-6.3.2" href="#section-6.3.2">6.3.2</a>.  Benchmark Metrics</span>

   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 <a href="#section-4">Section 4</a>, 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.

<span class="h4"><a class="selflink" id="section-6.3.3" href="#section-6.3.3">6.3.3</a>.  Measurement Accuracy</span>

   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.







<span class="grey">Poretsky, et al.              Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Reporting Format</span>

   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 (<a href="#section-5.6">Section 5.6</a>).

      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.




<span class="grey">Poretsky, et al.              Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


    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

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Test Cases</span>

   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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  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.




<span class="grey">Poretsky, et al.              Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   3.   Verify traffic is routed correctly.  Verify if traffic is
        forwarded without Impaired Packets [<a href="#ref-Po06" title="&quot;Terminology for Benchmarking Network-layer Traffic Control Mechanisms&quot;">Po06</a>].

   4.   Introduce Convergence Event [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

   5.   Measure First Route Convergence Time [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

   6.   Measure Full Convergence Time [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

   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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].  At the same time,
        measure number of Impaired Packets [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

   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 [<a href="#ref-Po11t" title="&quot;Terminology for Benchmarking Link-State IGP Data-Plane Route Convergence&quot;">Po11t</a>].

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Interface Failure and Recovery</span>

<span class="h4"><a class="selflink" id="section-8.1.1" href="#section-8.1.1">8.1.1</a>.  Convergence Due to Local Interface Failure and Recovery</span>

   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.






<span class="grey">Poretsky, et al.              Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h4"><a class="selflink" id="section-8.1.2" href="#section-8.1.2">8.1.2</a>.  Convergence Due to Remote Interface Failure and Recovery</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]), which may increase the
      measured convergence times and loss of connectivity periods.




<span class="grey">Poretsky, et al.              Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h4"><a class="selflink" id="section-8.1.3" href="#section-8.1.3">8.1.3</a>.  Convergence Due to ECMP Member Local Interface Failure and</span>
<span class="h4">        Recovery</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


<span class="h4"><a class="selflink" id="section-8.1.4" href="#section-8.1.4">8.1.4</a>.  Convergence Due to ECMP Member Remote Interface Failure and</span>
<span class="h4">        Recovery</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 [<a href="#ref-Sh10" title="&quot;A Framework for Loop-Free Convergence&quot;">Sh10</a>]), which may increase the
      measured convergence times and loss of connectivity periods.

<span class="h4"><a class="selflink" id="section-8.1.5" href="#section-8.1.5">8.1.5</a>.  Convergence Due to Parallel Link Interface Failure and Recovery</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Other Failures and Recoveries</span>

<span class="h4"><a class="selflink" id="section-8.2.1" href="#section-8.2.1">8.2.1</a>.  Convergence Due to Layer 2 Session Loss and Recovery</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 <a href="#section-4.1">Section 4.1</a>.

<span class="h4"><a class="selflink" id="section-8.2.2" href="#section-8.2.2">8.2.2</a>.  Convergence Due to Loss and Recovery of IGP Adjacency</span>

   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.



<span class="grey">Poretsky, et al.              Informational                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 <a href="#section-4.1">Section 4.1</a>.

<span class="h4"><a class="selflink" id="section-8.2.3" href="#section-8.2.3">8.2.3</a>.  Convergence Due to Route Withdrawal and Re-Advertisement</span>

   Objective:

      To obtain the IGP convergence measurements for route withdrawal
      and re-advertisement.








<span class="grey">Poretsky, et al.              Informational                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 <a href="#section-4.1">Section 4.1</a>.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  Administrative Changes</span>

<span class="h4"><a class="selflink" id="section-8.3.1" href="#section-8.3.1">8.3.1</a>.  Convergence Due to Local Interface Administrative Changes</span>

   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.



<span class="grey">Poretsky, et al.              Informational                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h4"><a class="selflink" id="section-8.3.2" href="#section-8.3.2">8.3.2</a>.  Convergence Due to Cost Change</span>

   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.





<span class="grey">Poretsky, et al.              Informational                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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 <a href="#section-4.1">Section 4.1</a>.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   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.




<span class="grey">Poretsky, et al.              Informational                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   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.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Acknowledgements</span>

   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.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>.  Normative References</span>

   [<a id="ref-Br91">Br91</a>]   Bradner, S., "Benchmarking terminology for network
            interconnection devices", <a href="./rfc1242">RFC 1242</a>, July 1991.

   [<a id="ref-Br97">Br97</a>]   Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-Br99">Br99</a>]   Bradner, S. and J. McQuaid, "Benchmarking Methodology for
            Network Interconnect Devices", <a href="./rfc2544">RFC 2544</a>, March 1999.

   [<a id="ref-Ca90">Ca90</a>]   Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual
            environments", <a href="./rfc1195">RFC 1195</a>, December 1990.

   [<a id="ref-Co08">Co08</a>]   Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for
            IPv6", <a href="./rfc5340">RFC 5340</a>, July 2008.

   [<a id="ref-De02">De02</a>]   Demichelis, C. and P. Chimento, "IP Packet Delay Variation
            Metric for IP Performance Metrics (IPPM)", <a href="./rfc3393">RFC 3393</a>,
            November 2002.

   [<a id="ref-Ho08">Ho08</a>]   Hopps, C., "Routing IPv6 with IS-IS", <a href="./rfc5308">RFC 5308</a>,
            October 2008.

   [<a id="ref-Ko02">Ko02</a>]   Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
            Metrics", <a href="./rfc3357">RFC 3357</a>, August 2002.

   [<a id="ref-Ma05">Ma05</a>]   Manral, V., White, R., and A. Shaikh, "Benchmarking Basic
            OSPF Single Router Control Plane Convergence", <a href="./rfc4061">RFC 4061</a>,
            April 2005.




<span class="grey">Poretsky, et al.              Informational                    [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   [<a id="ref-Ma05c">Ma05c</a>]  Manral, V., White, R., and A. Shaikh, "Considerations When
            Using Basic OSPF Convergence Benchmarks", <a href="./rfc4063">RFC 4063</a>,
            April 2005.

   [<a id="ref-Ma05t">Ma05t</a>]  Manral, V., White, R., and A. Shaikh, "OSPF Benchmarking
            Terminology and Concepts", <a href="./rfc4062">RFC 4062</a>, April 2005.

   [<a id="ref-Ma98">Ma98</a>]   Mandeville, R., "Benchmarking Terminology for LAN Switching
            Devices", <a href="./rfc2285">RFC 2285</a>, February 1998.

   [<a id="ref-Mo98">Mo98</a>]   Moy, J., "OSPF Version 2", STD 54, <a href="./rfc2328">RFC 2328</a>, April 1998.

   [<a id="ref-Ne07">Ne07</a>]   Newman, D. and T. Player, "Hash and Stuffing: Overlooked
            Factors in Network Device Benchmarking", <a href="./rfc4814">RFC 4814</a>,
            March 2007.

   [<a id="ref-Pa05">Pa05</a>]   Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions
            to RSVP-TE for LSP Tunnels", <a href="./rfc4090">RFC 4090</a>, May 2005.

   [<a id="ref-Po06">Po06</a>]   Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
            "Terminology for Benchmarking Network-layer Traffic Control
            Mechanisms", <a href="./rfc4689">RFC 4689</a>, October 2006.

   [<a id="ref-Po11t">Po11t</a>]  Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology
            for Benchmarking Link-State IGP Data-Plane Route
            Convergence", <a href="./rfc6412">RFC 6412</a>, November 2011.

   [<a id="ref-Sh10">Sh10</a>]   Shand, M. and S. Bryant, "A Framework for Loop-Free
            Convergence", <a href="./rfc5715">RFC 5715</a>, January 2010.

   [<a id="ref-Sh10i">Sh10i</a>]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
            <a href="./rfc5714">RFC 5714</a>, January 2010.

   [<a id="ref-Th00">Th00</a>]   Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
            Multicast Next-Hop Selection", <a href="./rfc2991">RFC 2991</a>, November 2000.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>.  Informative References</span>

   [<a id="ref-Al00">Al00</a>]   Alaettinoglu, C., Jacobson, V., and H. Yu, "Towards
            Millisecond IGP Convergence", NANOG 20, October 2000.

   [<a id="ref-Al02">Al02</a>]   Alaettinoglu, C. and S. Casner, "ISIS Routing on the Qwest
            Backbone: a Recipe for Subsecond ISIS Convergence",
            NANOG 24, February 2002.

   [<a id="ref-Fi02">Fi02</a>]   Filsfils, C., "Tutorial: Deploying Tight-SLA Services on an
            Internet Backbone: ISIS Fast Convergence and Differentiated
            Services Design", NANOG 25, June 2002.



<span class="grey">Poretsky, et al.              Informational                    [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc6413">RFC 6413</a>          IGP Convergence Benchmark Methodology    November 2011</span>


   [<a id="ref-Fr05">Fr05</a>]   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.

   [<a id="ref-Ka02">Ka02</a>]   Katz, D., "Why are we scared of SPF? IGP Scaling and
            Stability", NANOG 25, June 2002.

   [<a id="ref-Vi02">Vi02</a>]   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]
</pre>