Network Working Group S. Poretsky~~Internet Draft~~Internet-DraftAllot Communications~~Expires: September 08, 2009~~Intended~~Status:~~status:Informational~~Brent~~B.ImhoffExpires: January 14, 2010Juniper Networks~~March 08,~~K. Michielsen Cisco Systems July 13,2009 Terminology for Benchmarking Link-State IGP Data Plane Route Convergence~~<draft-ietf-bmwg-igp-dataplane-conv-term-17.txt>~~draft-ietf-bmwg-igp-dataplane-conv-term-18Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on~~September 8, 2009.~~January 14, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.~~ABSTRACT~~AbstractThis document describes the terminology for benchmarking Interior Gateway Protocol (IGP) Route Convergence. The terminology is to be used for benchmarking IGP convergence time through externally observable (black box) data plane measurements. The terminology can be applied to any link-state IGP, such as ISIS and OSPF.~~Link-State IGP Data Plane Route Convergence~~Table of Contents 1. Introduction and~~Scope........................................3~~Scope . . . . . . . . . . . . . . . . . . . . 42. Existing Definitions~~.........................................4~~. . . . . . . . . . . . . . . . . . . . . 43. Term~~Definitions..............................................4 3.1 States 3.1.1~~Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Convergence Types . . . . . . . . . . . . . . . . . . . . 5 3.1.1.Route~~Convergence....................................4 3.1.2~~Convergence . . . . . . . . . . . . . . . . . . 5 3.1.2.Full~~Convergence.....................................5 3.1.3 Network Convergence..................................5 3.1.4 Route-Specific Convergence...........................6 3.1.5 Stale Forwarding.....................................6 3.2 Events 3.2.1~~Convergence~~Event....................................7 3.2.2~~. . . . . . . . . . . . . . . . . . . 5 3.1.3. NetworkConvergence~~Event Trigger............................7 3.2.3~~. . . . . . . . . . . . . . . . . 6 3.2. Instants . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1.Convergence Event~~Instant............................8 3.2.4~~Instant . . . . . . . . . . . . . . 6 3.2.2.Convergence Recovery~~Instant.........................8 3.2.5~~Instant . . . . . . . . . . . . . 7 3.2.3.First Route Convergence~~Instant......................9 3.2.6~~Instant . . . . . . . . . . . 7 3.3. Transitions . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1.Convergence Event~~Transition.........................9 3.2.7~~Transition . . . . . . . . . . . . . 8 3.3.2.Convergence Recovery~~Transition......................10 3.2.8 Nested Convergence Events............................10 3.3~~Transition . . . . . . . . . . . 9 3.4.Interfaces~~3.3.1~~. . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1.Local~~Interface......................................11 3.3.2 Neighbor Interface...................................11 3.3.3~~Interface . . . . . . . . . . . . . . . . . . . 9 3.4.2.Remote~~Interface.....................................11 3.3.4~~Interface . . . . . . . . . . . . . . . . . . . 10 3.4.3.Preferred Egress~~Interface...........................12 3.3.5~~Interface . . . . . . . . . . . . . . 10 3.4.4.Next-Best Egress~~Interface...........................12 3.4~~Interface . . . . . . . . . . . . . . 10 3.5.Benchmarking~~Method 3.4.1 Packet Loss..........................................13 3.4.2 Convergence Packet Loss..............................13 3.4.3~~Methods . . . . . . . . . . . . . . . . . . . 11 3.5.1.Rate-Derived~~Convergence Method......................14 3.4.4~~Method . . . . . . . . . . . . . . . . . 11 3.5.2.Loss-Derived~~Convergence Method......................14 3.4.5 Packet Sampling Interval.............................15 3.5~~Method . . . . . . . . . . . . . . . . . 12 3.5.3. Route-Specific Loss-Derived Method . . . . . . . . . . 13 3.6.Benchmarks~~3.5.1~~. . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.1.Full Convergence~~Time................................17 3.5.2~~Time . . . . . . . . . . . . . . . . 15 3.6.2.First Route Convergence~~Time.........................17 3.5.3~~Time . . . . . . . . . . . . . 15 3.6.3.Route-Specific Convergence~~Time......................17 3.5.4~~Time . . . . . . . . . . . 16 3.6.4. Loss-Derived Convergence Time . . . . . . . . . . . . 18 3.6.5. Route Loss of Connectivity Period . . . . . . . . . . 19 3.6.6. Loss-Derived Loss of Connectivity Period . . . . . . . 20 3.7. Measurement Terms . . . . . . . . . . . . . . . . . . . . 21 3.7.1. Convergence Event . . . . . . . . . . . . . . . . . . 21 3.7.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . 21 3.7.3. Convergence Packet Loss . . . . . . . . . . . . . . . 21 3.7.4. Connectivity Packet Loss . . . . . . . . . . . . . . . 22 3.7.5. Packet Sampling Interval . . . . . . . . . . . . . . . 23 3.7.6.Sustained Convergence Validation~~Time................18 3.5.5 Reversion~~Time . . . . . . . . 23 3.8. Miscellaneous Terms . . . . . . . . . . . . . . . . . . . 24 3.8.1. Stale Forwarding . . . . . . . . . . . . . . . . . . . 24 3.8.2. NestedConvergence~~Time...........................19~~Event . . . . . . . . . . . . . . . 244.~~IANA Considerations...........................................19 5.~~Security~~Considerations.......................................19~~Considerations . . . . . . . . . . . . . . . . . . . 25 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 256.~~Acknowledgements..............................................20~~Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 257.~~References....................................................20 8. Author's Address..............................................21 Link-State IGP Data Plane Route Convergence~~References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 261. Introduction and Scope This draft describes the terminology for benchmarkingLink-StateInterior Gateway Protocol (IGP)~~Route~~Convergence. The motivation and applicability for this benchmarking is provided in~~[Po07a].~~[Po09a].The methodology to be used for this benchmarking is described in~~[Po07m].~~[Po09m].The purpose of this document is to introduce new terms required to complete execution of the IGP Route~~Convergence~~Methodology~~[Po07m]. These terms apply to IPv4 and IPv6 traffic and IGPs. Convergence times are~~[Po09m]. IGP convergence time ismeasured~~at the Tester~~on the data planeat the Testerby observing packet loss through the DUT. The methodology and terminology to be used for benchmarking~~Route~~IGPConvergence can be applied to~~any~~IPv4 and IPv6 traffic andlink-state~~IGP~~IGPssuch as ISIS~~[Ca90] and~~[Ca90][Ho08],OSPF~~[Mo98]. The data plane is measured to obtain black-box (externally observable) convergence benchmarking metrics. When there is no packer loss observed in the data plane, the convergence time SHALL be reported as zero. An example of Route Convergence as observed~~[Mo98][Co08],and~~measured from the data plane is shown in Figure 1. The graph in Figure 1 shows Forwarding Rate versus Time. Time 0 on the X-axis is on the far right of the graph. The Offered Load to the ingress interface of the DUT SHOULD equal the measured Throughput [Ba99][Ma98] of the DUT and the Forwarding Rate [Ma98] and Convergence Packet Loss is measured at the Preferred and Next-Best Egress interfaces of the DUT befire, during, and after a Convergence Event Trigger. These components of the graph are defined in the Term Definitions section. Full Convergence-> Convergence Convergence Recovery Event Event Time= Instant Instant Trigger 0sec Forwarding Rate= ^ ^ ^ ^ Offered Load= Offered Load --> ------\ Packet /----------- <--Max Throughput \ Loss /<----Convergence Convergence------->\ / Event Transition Recovery Transition \ / \_____/<------Maximum Packet Loss ^ First Route Convergence Instant Y-axis = Forwarding Rate X-axis = Time (increases right to left to match commercial test equipment displays) Figure 1. Convergence Graph Link-State IGP Data Plane Route Convergence 2. Existing Definitions This document uses existing terminology defined~~others. 2. Existing Definitions This document uses existing terminology definedin other BMWG work. Examples include, but are not limited to:~~Latency [Ref.[Ba91], section 3.8]~~Frame Loss Rate~~[Ref.[Ba91],~~[Ref.[Br91],section 3.6] Throughput~~[Ref.[Ba91],~~[Ref.[Br91],section 3.17]Offered Load [Ref.[Ma98], section 3.5.2] Forwarding Rate [Ref.[Ma98], section 3.6.1]Device Under Test (DUT) [Ref.[Ma98], section 3.1.1] System Under Test (SUT) [Ref.[Ma98], section 3.1.2] Out-of-order Packet [Ref.[Po06], section 3.3.2] Duplicate Packet [Ref.[Po06], section 3.3.3] Packet Reordering [Ref.[Mo06], section 3.3]Stream [Ref.[Po06], section 3.3.2] Flow [Ref.[Po06], section 3.1.5] Forwarding Delay [Ref.[Po06], section 3.2.4] Loss Period [Ref.[Ko02], section 4]The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [Br97]. RFC 2119 defines the use of these key words to help make the intent of standards track documents as clear as possible. While this document uses these keywords, this document is not a standards track document. 3. Term Definitions~~3.1 States 3.1.1~~3.1. Convergence Types 3.1.1.Route Convergence Definition: The~~action to update~~process of updatingall components of the~~router with the most recent route change(s)~~router,including the Routing Information Base (RIB) and Forwarding Information Base (FIB), along with software and hardware tables,with the most recent route change(s)such that forwarding~~is successful~~for~~one or more~~aroute~~entries.~~entry is successful on the Next-Best Egress Interface.Discussion: Route Convergence MUST occur after a Convergence Event. Route Convergence can be observed externally by the rerouting of data trafficfor a destination matching a route entryto the Next-best Egress Interface.~~Also, completion~~Completionof Route Convergence may or may not be sustained over time. Measurement Units: N/A Issues: None See Also: Network~~Convergence~~Convergence,Full~~Convergence~~Convergence,Convergence Event~~Link-State IGP Data Plane Route Convergence 3.1.2~~3.1.2.Full Convergence Definition: Route Convergence for~~an entire FIB~~all routesin~~which complete recovery from the Convergence Event is indicated by the DUT throughput equal to the offered load. Discussion: When benchmarking convergence, it is useful to measure~~the~~time to converge an entire~~FIB.~~For example,~~Discussion: Full Convergence MUST occur aftera Convergence~~Event~~Event. Full Convergencecan be~~produced for an OSPF table of 5000 routes so that~~observed externally bythe~~time to converge routes 1 through 5000 is measured. Completion~~reroutingof~~Full~~data traffic to destinations matching all route entries to the Next-best Egress Interface. Completion of FullConvergence is externally observable from the data plane when the~~Throughput~~Forwarding Rateof the data plane traffic on the Next-Best Egress Interface equals the~~offered load. Full Convergence MAY be measured using Rate-Derived Convergence Method or calculated using Loss-Derived Convergence Method.~~Offered Load. Completion ofFull Convergence may or may not be sustained over time.~~The Sustained Convergence Validation Time MUST be applied.~~Measurement Units: N/A Issues: None See Also: Network~~Convergence~~Convergence,RouteConvergence, Convergence Event, FullConvergenceTime,Convergence~~Event 3.1.3~~Recovery Instant 3.1.3.Network Convergence Definition:~~The process of updating of all routing tables, including distributed FIBs,~~Full Convergencein all routers throughout the network. Discussion: Network Convergence~~requires completion of~~includesall Route Convergence operations for all routers in the network following a Convergence Event. Completion of Network Convergence can be observed by recovery of~~System Under Test (SUT) Throughput~~the network Forwarding Rateto equal the~~offered load,~~Offered Load,with no Stale Forwarding, and no Blenders [Ca01][Ci03].Completion of Network Convergence may or may not be sustained over time.Measurement Units: N/A Issues: None~~Link-State IGP Data Plane Route Convergence~~See Also: Route~~Convergence~~Convergence, Full Convergence,Stale Forwarding~~3.1.4 Route-Specific~~3.2. Instants 3.2.1.ConvergenceEvent InstantDefinition:~~Route~~The time instant that aConvergence~~for one or more specific route entries in the FIB in which recovery from~~Event occurs. Discussion: Ifthe Convergence Event~~is indicated when data-plane~~causes instantaneoustraffic~~for the flow [Po06] matching that route entry(ies) is routed to~~loss onthe~~Next-Best~~PreferredEgress~~Interface. Discussion: When benchmarking convergence, it is sometimes useful to measure the time to converge a single flow [Po06] or group of flows to benchmark convergence time for one or a few route entries in the FIB instead of~~Interface,the~~entire FIB. Route-Specific~~Convergence~~of a flow~~Event Instantis~~externally~~observable from the data plane~~when~~asthe~~data plane traffic for~~instantthat~~flow is routed~~the DUT beginstoexhibit packet loss. The Tester SHOULD collect a timestamp onthe~~Next-Best Egress Interface.~~Convergence Event Instant if it is not observable from the data plane.Measurement Units:~~N/A~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.Issues: None See Also:~~Full Convergence Route Convergence~~Convergence Event~~3.1.5 Stale Forwarding~~3.2.2. Convergence Recovery InstantDefinition:~~Forwarding of traffic to route entries that no longer exist or to route entries with next-hops~~The time instantthat~~are no longer preferred.~~Full Convergence has completed.Discussion:~~Stale Forwarding can~~The Full Convergence completed state MUSTbe~~caused by a~~maintained for an interval of duration equal to the SustainedConvergence~~Event and can manifest as a "black-hole" or microloop that produces packet loss. Stale Forwarding can exist until Network~~Validation Time in order to validate the Convergence Recovery Instant. TheConvergenceRecovery Instantis~~completed. Stale Forwarding cannot be~~observable from the data plane as the instant the DUT forwards traffic to all destinations over the Next-Best Egress Interface. When using the Rate-Derived Method, the Convergence Recovery Instant falls within the Packet Sampling Interval preceding the first interval where theobserved~~with a single DUT.~~Forwarding Rate on the Next-Best Egress Interface equals the Offered Load.Measurement Units:~~N/A~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.Issues: None See Also:~~Network~~SustainedConvergence~~Link-State IGP Data Plane Route~~Validation Time, FullConvergence~~3.2 Events 3.2.1~~3.2.3. First RouteConvergence~~Event~~InstantDefinition: The~~occurrence of~~time instant the first route entry completes Route Convergence followinga~~planned or unplanned event in~~Convergence Event Discussion: Any route may bethe~~network~~first to complete Route Convergence. The First Route Convergence Instant is observable from the data plane as the instantthat~~results in a change in~~the~~egress interface of~~first packet is received fromthe~~Device Under Test (DUT) for routed packets. Discussion: Convergence Events include link loss, routing protocol session loss, router failure, configuration change, and better next-hop learned via a routing protocol.~~Next-Best Egress Interface.Measurement Units:~~N/A~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.Issues: None See Also:RouteConvergence~~Packet Loss Convergence Event Instant 3.2.2~~3.3. Transitions 3.3.1.Convergence Event~~Trigger~~TransitionDefinition:~~An action taken by the Tester to produce~~A time interval followinga Convergence~~Event. Discussion: The Convergence~~Event~~Trigger is introduced by~~in which Forwarding Rate onthe~~Tester and~~Preferred Egress Interface gradually reduces to zero. Discussion: The Forwarding Rate during a Convergence Event Transition may not decrease linearly. The Forwarding Rate observed on all DUT egress interfacesmay~~be indicated by link loss, routing protocol session loss, router failure, configuration change,~~or~~a better next-hop learned via a routing protocol introduced by~~may not decrease to zero. The Offered Load,the~~Tester.~~number of routes, and the Packet Sampling Interval influence the observations of the Convergence Event Transition using the Rate-Derived Method. This is further discussed with the term "Rate-Derived Method".Measurement Units:~~N/A~~secondsIssues: None See Also: Convergence~~Event Convergence Packet Loss~~Event, Rate-Derived Method 3.3.2.Convergence Recovery~~Instant Link-State IGP Data Plane Route Convergence 3.2.3 Convergence Event Instant~~TransitionDefinition:~~The~~Atime~~instant that a~~interval following the First RouteConvergence~~Event becomes observable~~Instantinwhich Forwarding Rate onthe~~data plane.~~Next-Best Egress Interface gradually increases to equal the Offered Load.Discussion:The Forwarding Rate observed during aConvergence~~Event Instant is observable from~~Recovery Transition may not increase linearly. The Offered Load,the~~data plane as~~number of routes, andthe~~precise time that~~Packet Sampling Interval influencethe~~device under test begins to exhibit packet loss. The Convergence Event Instant is produced by~~observations ofthe Convergence~~Event Trigger. The Convergence Event Instant always occurs concurrent or subsequent to~~Recovery Transition usingthe~~Tester introducing~~Rate-Derived Method. This is further discussed withthe~~Convergence Event Trigger.~~term "Rate-Derived Method".Measurement Units:~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.~~secondsIssues: None See Also:~~Convergence Event Convergence Packet Loss Convergence Recovery Instant 3.2.4 Convergence Recovery Instant Definition: The time instant that~~FullConvergence,First RouteConvergence~~completion is observed. Discussion: Convergence Recovery Instant is measurable from~~Instant, Rate-Derived Method 3.4. Interfaces 3.4.1. Local Interface Definition: An interface onthe~~data plane as~~DUT. Discussion: A failure ofthe~~precise time~~Local Interface indicatesthat the~~device under test completes Full Convergence. The Convergence Recovery Instant MUST be maintained for an interval of duration equal to~~failure occurred directly onthe~~Sustained Convergence Validation Time.~~DUT.Measurement Units:~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.~~N/AIssues: None See Also:~~Sustained Convergence Validation Time Convergence Packet Loss Convergence Event Instant Link-State IGP Data Plane Route Convergence 3.2.5 First Route Convergence Instant~~Remote Interface 3.4.2. Remote InterfaceDefinition:~~The time instant a first route entry has converged following~~An interface ona~~Convergence Event, as observed by receipt of the first packet from the Next-Best Egress Interface. Discussion: The First Route Convergence Instant is an indication~~neighboring routerthat~~the process to achieve Full Convergence has begun. Any route may be the first~~is not directly connectedto~~converge for First Route Convergence Instant. Measurement~~any interfaceon the~~data-plane enables~~DUT. Discussion: A failure of a Remote Interface indicates thatthe~~First Route Convergence Instant~~failure occurred on a neighbor router's interface that is not directly connectedto~~be observed without any white-box information from~~the DUT. Measurement Units:~~hh:mm:ss:nnn:uuu, where 'nnn' is milliseconds and 'uuu' is microseconds.~~N/AIssues: None See Also:~~Route Convergence Full Convergence Stale Forwarding 3.2.6 Convergence Event Transition~~Local Interface 3.4.3. Preferred Egress InterfaceDefinition:~~A time interval observed following a Convergence Event in which Throughput gradually reduces~~The outbound interface from the DUT for traffic routedto~~a minimum value.~~the preferred next-hop.Discussion: The~~Convergence Event Transition~~Preferred Egress Interfaceis~~best observed for Full Convergence. The~~theegress~~packet rate observed during~~interface prior toa Convergence~~Event Transition may not decrease linearly and may not decrease to zero. Both the offered load and the Packet Sampling Interval influence the observations of the Convergence Event Transition. For example, it is possible that if the Convergence Event were to cause the Throughput [Ba91] to drop to zero then this may not be observed if the Packet Sampling Interval is set too high. This is further discussed with the term "Packet Sampling Interval".~~Event.Measurement Units:~~seconds~~N/AIssues: None~~Link-State IGP Data Plane Route Convergence~~See Also:~~Convergence Event Full Convergence Packet Sampling Interval 3.2.7 Convergence Recovery Transition~~Next-Best Egress Interface 3.4.4. Next-Best Egress InterfaceDefinition: The~~characteristic of~~outbound interface fromthe DUT~~in which Throughput gradually increases~~for traffic routedto~~equal~~the~~offered load. Discussion: The Convergence Recovery Transition is~~second-best~~observed for Full Convergence.~~next-hop. Discussion:TheNext-Best Egress Interface becomes theegress~~packet rate observed during~~interface aftera Convergence~~Recovery Transition may not increase linearly. Both the offered load and the Packet Sampling Interval influence the observations~~Event. The Next-Best Egress Interface isof the~~Convergence Recovery Transition. This is further discussed with~~same media type and link speed asthe~~term "Packet Sampling Interval".~~Preferred Egress Interface.Measurement Units:~~seconds~~N/AIssues: None See Also:~~Full Convergence Packet Sampling Interval 3.2.8 Nested Convergence Events~~Preferred Egress Interface 3.5. Benchmarking Methods 3.5.1. Rate-Derived MethodDefinition: The~~occurrence of a Convergence Event while the route table is converging~~method to calculate convergence time benchmarksfrom~~a prior Convergence Event.~~observing Forwarding Rate each Packet Sampling Interval.Discussion:~~The~~Figure 1 shows an example of the Forwarding Rate change in time during convergence as observed when using the Rate-Derived Method. ^Convergence~~Events for a Nested~~Fwd | Recovery Rate | Instant | Offered ^ | Load --> ----------\ /----------- | \ /<---Convergence~~Event MUST occur with different neighbors. A common observation from a Nested~~| \ Packet / Recovery |Convergence--->\ Loss / Transition |Event~~will be the withdrawal~~\ / | Transition \---------/ <-- Max Packet Loss | +---------------------------------------------------------> ^ ^ time Convergence First Route Event Instant Convergence Instant Figure 1: Rate-Derived Convergence Graph The Offered Load SHOULD consists of a single Stream [Po06]. If sending multiple Streams, the measured traffic rate statistics for all Streams MUST be added together. The destination addresses for the Offered Load MUST be distributed such that all routes in the FIB are matched and each route is offered an equal share of the total Offered Load. At least one packet per route in the FIB for all routes in the FIB MUST be offered to the DUT within each Packet Sampling Interval. The Offered Load, the number of routes, and the Packet Sampling Interval influence the observations for the Rate-Derived Method. It may be difficult to identify the different convergence time instants in the Rate-Derived Convergence Graph. For example, it is possible that a Convergence Event causes the Forwarding Rate to drop to zero, while this may not be observed in the Forwarding Rate measurements if the Packet Sampling Interval is too high. Metrics measured at the Packet Sampling Interval MUST include Forwarding Rate and packet loss. Rate-Derived Method is a RECOMMENDED method to measure convergence time benchmarks. To measure convergence time benchmarks for Convergence Events that do not cause instantaneous traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD collect a timestamp of the Convergence Event Instant and the Tester SHOULD observe Forwarding Rate seperately on the Next-Best Egress Interface. Since the Rate-Derived Method does not distinguish between individual traffic destinations, it SHOULD NOT be used for any route specific measurements. Therefor Rate-Derived Method SHOULD NOT be used to benchmark Route Loss of Connectivity Period. Measurement Units: N/A Issues: None See Also: Packet Sampling Interval, Convergence Event, Convergence Event Instant, Full Convergence 3.5.2. Loss-Derived Method Definition: The method to calculate the Loss-Derived Convergence Time and Loss- Derived Loss of Connectivity Period benchmarks from the amount of packet loss. Discussion: The Offered Load SHOULD consists of a single Stream [Po06]. If sending multiple Streams, the measured traffic rate statistics for all Streams MUST be added together. The destination addresses for the Offered Load MUST be distributed such that all routes in the FIB are matched and each route is offered an equal share of the total Offered Load. Loss-Derived Method SHOULD always be combined with Rate-Derived Method in order to observe Full Convergence completion. The total amount of Convergence Packet Loss is collected after Full Convergence completion. To measure convergence time and loss of connectivity benchmarks, the Tester SHOULD in general observe packet loss on all DUT egress interfaces (Connectivity Packet Loss). To measure convergence time benchmarks for Convergence Events that do not cause instantaneous traffic loss for all routes at the Convergence Event Instant, the Tester SHOULD collect a timestamp of the Convergence Event Instant and the Tester SHOULD observe packet loss seperately on the Next-Best Egress Interface (Convergence Packet Loss). Since Loss-Derived Method does not distinguish between traffic destinations and the packet loss statistics are only collected after Full Convergence completion, this method can only be used to measure average values over all routes. For these reasons Loss-Derived Method can only be used to benchmark Loss-Derived Convergence Time and Loss-Derived Loss of Connectivity Period. Note that the Loss-Derived Method measures an average over all routes, including the routes that may not be impacted by the Convergence Event, such as routes via non-impacted members of ECMP or parallel links. Measurement Units: seconds Issues: None See Also: Loss-Derived Convergence Time, Loss-Derived Loss of Connectivity Period, Convergence Packet Loss 3.5.3. Route-Specific Loss-Derived Method Definition: The method to calculate the Route-Specific Convergence Time benchmark from the amount of packet loss during convergence for a specific route entry. Discussion: To benchmark Route-Specific Convergence Time, the Tester provides an Offered Load that consists of multiple Streams [Po06]. Each Stream has a single destination address matching a different route entry, for every route entry in the FIB. Convergence Packet Loss is measured for each Stream separately. Route-Specific Loss-Derived Method SHOULD always be combined with Rate-Derived Method in order to observe Full Convergence completion. The total amount of Convergence Packet Loss for each Stream is collected after Full Convergence completion. Route-Specific Loss-Derived Method is a RECOMMENDED method to measure convergence time benchmarks. To measure convergence time and lossofconnectivity benchmarks, the Tester SHOULD in general observe packet loss on all DUT egress interfaces (Connectivity Packet Loss). To measure convergence time benchmarks for Convergence Events that do not cause instantaneous traffic loss for allroutes~~from one neighbor while~~atthe~~routes of another neighbor are being installed. Measurement Units: N/A Issues: None See Also:~~Convergence Event~~Link-State IGP Data Plane Route Convergence 3.3 Interfaces 3.3.1 Local Interface Definition: An interface on~~Instant,the~~DUT. Discussion: A failure~~Tester SHOULD collect a timestampof the~~Local Interface indicates that~~Convergence Event Instant andthe~~failure occurred directly~~Tester SHOULD observe packet loss seperatelyon the~~DUT. Measurement Units: N/A Issues: None See Also: Neighbor Interface Remote Interface 3.3.2 Neighbor~~Next-Best EgressInterface~~Definition: The interface on the neighbor router or tester that is directly linked~~(Convergence Packet Loss). Since Route-Specific Loss-Derived Method uses traffic streamsto~~the DUT's Local Interface. Discussion: A failure of a Neighbor Interface indicates that a failure occurred on~~individual routes, it measures packet loss as it would be experienced bya~~neighbor router's interface that directly links the neighbor router~~network user. For this reason Route-Specific Loss-Derived Method is RECOMMENDEDto~~the DUT.~~measure Route-Specific Convergence Time benchmarks and Route Loss of Connectivity Period benchmarks.Measurement Units:~~N/A~~secondsIssues: None See Also:~~Local Interface Remote Interface 3.3.3 Remote Interface~~Route-Specific Convergence Time, Route Loss of Connectivity Period, Convergence Packet Loss 3.6. Benchmarks 3.6.1. Full Convergence TimeDefinition:~~An interface on a neighboring router that is not directly connected to any interface on~~The time duration ofthe~~DUT.~~period between the Convergence Event Instant and the Convergence Recovery Instant as observed using the Rate- Derived Method.Discussion:~~A failure of a Remote Interface indicates that~~Usingthe~~failure occurred on a neighbor router's interface that is not directly connected to~~Rate-Derived Method, Full Convergence Time can be calculated asthe~~DUT. Link-State IGP Data Plane Route~~time difference between the Convergence Event Instant and the Convergence Recovery Instant, as shown in Equation 1. Full Convergence Time = Convergence Recovery Instant -Convergence~~Measurement Units: N/A Issues: None See Also: Local Interface Neighbor Interface 3.3.4 Preferred Egress Interface Definition:~~Event Instant Equation 1The~~outbound interface~~Convergence Event Instant can be derivedfrom the~~DUT for traffic routed to~~Forwarding Rate observation or from a timestamp collected bythe~~preferred next-hop. Discussion: The Preferred Egress Interface~~Tester. For the testcases described in [Po09m], itisexpected that Full Convergence Time equalsthe~~egress interface prior~~maximum Route-Specific Convergence Time when benchmarking all routes in FIB using the Route-Specific Loss- Derived Method. It is not possibleto~~a~~measure FullConvergence~~Event.~~Time using the Loss- Derived Method.Measurement Units:~~N/A~~secondsIssues: None See Also:~~Next-Best Egress Interface 3.3.5 Next-Best Egress Interface~~Full Convergence, Rate-Derived Method, Route-Specific Loss-Derived Method 3.6.2. First Route Convergence TimeDefinition: The~~outbound interface from the DUT for traffic routed to~~duration ofthe~~second-best next-hop. It is~~period betweenthe~~same media type~~Convergence Event Instantand~~link speed~~the First Route Convergence Instantasobserved usingthe~~Preferred Egress Interface~~Rate- Derived Method.Discussion:~~The Next-Best Egress Interface becomes~~Usingthe~~egress interface after a Convergence Event. Measurement Units: N/A Issues: None See Also: Preferred Egress Interface Link-State IGP Data Plane~~Rate-Derived Method, FirstRoute Convergence~~3.4 Benchmarking Methods 3.4.1 Packet Loss Definition: The number of packets that should have been forwarded by a DUT under a constant offered load that were not forwarded due to lack of resources. Discussion: Packet Loss is a modified version of~~Time can be calculated asthe~~term "Frame Loss Rate"~~time difference between the Convergence Event Instant and the First Route Convergence Instant,as~~defined in [Ba91]. The term "Frame Loss" is intended for Ethernet Frames while "Packet Loss" is intended for IP packets. Packet Loss~~shown with Equation 2. First Route Convergence Time = First Route Convergence Instant - Convergence Event Instant Equation 2 The Convergence Event Instantcan be~~measured as a reduction in forwarded traffic~~derivedfrom the~~Throughput [Ba91] of~~Forwarding Rate observation or from a timestamp collected bythe~~DUT. Measurement units: Number of offered packets~~Tester. For the testcases described in [Po09m], it is expectedthat~~are~~First Route Convergence Time equals the minimum Route-Specific Convergence Time when benchmarking all routes in FIB using the Route-Specific Loss-Derived Method. It isnot~~forwarded.~~possible to measure First Route Convergence Time using the Loss-Derived Method. Measurement Units: secondsIssues: None See Also:Rate-Derived Method, Route-Specific Loss-Derived Method, First RouteConvergence~~Packet Loss 3.4.2~~Instant 3.6.3. Route-SpecificConvergence~~Packet Loss~~TimeDefinition: The~~number~~amountof~~packets lost due~~time it takes for Route Convergencetobe completed fora~~Convergence Event until Full Convergence completes.~~specific route, as calculated from the amount of packet loss during convergence for a single route entry.Discussion:Route-SpecificConvergence~~Packet Loss includes packets that were lost and packets that were delayed due to buffering. The Convergence Packet Loss observed in a Packet Sampling Interval may or may not~~Time can onlybe~~equal to~~measured usingthe~~number of packets in~~Route- Specific Loss-Derived Method. Ifthe~~offered load during~~applied Convergence Event causes instantaneous traffic loss for all routes atthe~~interval following a~~Convergence Event~~(see Figure 1). Measurement Units: number of packets Issues: None See Also:~~Instant, ConnectivityPacket Loss~~Route Convergence Convergence Event~~should be observed. ConnectivityPacket~~Sampling Interval Link-State IGP Data Plane Route Convergence 3.4.3 Rate-Derived Convergence Method Definition: The method to calculate convergence time benchmarks from~~Loss isthe~~amount of time that~~combined packet loss observed on Preferred Egress Interface and Next-Best Egress Interface. When benchmarking Route-Specific Convergence Time, Connectivity Packet Loss is measured and Equation 3 is applied for each measured route. The calculation is equal to Equation 7 in Section 3.6.5. Route-SpecificConvergenceTime = ConnectivityPacket Loss~~persists upon occurrence of a~~for specific route/Offered Load per route Equation 3 If the appliedConvergence~~Event. Rate-Derived~~Event does not cause instantaneous traffic loss for all routes at theConvergence~~Method can be calculated as~~Event Instant, thenthe~~time difference from~~Tester SHOULD collect a timestamp ofthe Convergence Event Instant~~to~~andtheTester SHOULD observeConvergence~~Recovery Instant, as shown with~~Packet Loss separately on the Next- Best Egress Interface. When benchmarking Route-Specific Convergence Time, Convergence Packet Loss is measured andEquation~~1. (Equation 1) Rate-Derived~~4 is applied for each measured route. Route-SpecificConvergence~~Method~~Time= Convergence~~Recovery~~Packet Loss for specific route/Offered Load per route - (Convergence EventInstant -start traffic instant) Equation 4 TheConvergence Event~~Instant. Discussion: It is RECOMMENDED that the Rate-Derived Convergence Method~~Instant and start traffic instant SHOULDbe~~measured when benchmarking convergence times.~~collected by the Tester.The~~Rate-Derived~~Route-SpecificConvergence~~Method SHOULD~~Time benchmarks enable minimum, maximum, average, and median convergence time measurements tobe~~measured with an Offered Load at~~reported by comparingthe~~Throughput of~~results forthe~~DUT. At least one packet per~~differentroute~~in the FIB~~entries. It also enables benchmarking of convergence time when configuring a priority valuefor~~all routes in the FIB MUST~~route entry(ies). Since multiple Route-Specific Convergence Times canbe~~offered to the DUT within the Packet Sampling Interval. It~~measured itis possible to~~measure no packet loss, which results in a Rate-Derived Convergence Time benchmark~~have an arrayof~~zero. Failure to achieve Full Convergence results in a Rate-Derived~~results. The format for reporting Route-SpecificConvergence Time~~benchmark of infinity.~~is provided in [Po09m].Measurement Units: seconds Issues: None See Also: Convergence~~Packet Loss Convergence Recovery Instant~~Event,Convergence~~Event Instant Full~~Packet Loss, Connectivity Packet Loss, RouteConvergence~~3.4.4~~3.6.4.Loss-Derived Convergence~~Method Definition: The method to calculate convergence~~Time Definition: The average Route Convergencetime~~benchmarks~~for all routes in FIB, as calculatedfrom the amount ofpacket loss during convergence. Discussion: Loss-DerivedConvergence~~Packet Loss.~~Time is measured using theLoss-DerivedMethod. If the appliedConvergence~~Method can~~Event causes instantaneous traffic loss for all routes at the Convergence Event Instant, Connectivity Packet Loss shouldbe~~calculated from~~observed. Connectivity Packet Loss is the combined packet loss observed on Preferred Egress Interface and Next-Best Egress Interface. When benchmarking Loss-DerivedConvergenceTime, ConnectivityPacket Loss~~as shown with Equation 2.~~is measured andEquation~~2 -~~5 is applied.Loss-Derived Convergence~~Method~~Time=~~Convergence Packets Loss / Offered~~Connectivity Packet Loss/OfferedLoad~~where units are packets / packets/second = seconds Link-State IGP Data Plane Route Convergence Discussion: Ideally,~~Equation 5 IftheappliedConvergence Event~~Transition and Convergence Recovery Transition are~~does not causeinstantaneous~~so that the Rate-Derived Convergence Method = Loss-Derived Convergence Method. However, router implementations are less than ideal. Loss-Derived Convergence Method gives a better than actual result when converging many~~traffic loss for allroutes~~simultaneously because it ignores~~atthe~~transitions. The Rate-Derived~~Convergence~~Method takes~~Event Instant, thenthe~~transitions into account. Equation 2 calculates~~Tester SHOULD collect a timestamp ofthe~~average convergence time over all routes to which packets have been sent. The average convergence time is often lower than~~Convergence Event Instant andthe~~maximum convergence time over all routes, so it can produce a result that is faster than~~Tester SHOULD observe Convergence Packet Loss separately onthe~~actual convergence time.. Therefore,~~Next- Best Egress Interface. When benchmarkingLoss-Derived Convergence~~Method~~Time, Convergence Packet Lossis~~not the preferred method to measure convergence benchmarks. For these reasons the RECOMMENDED method to obtain a benchmark metric for convergence time~~measured and Equation 6is~~the Rate-Derived~~applied. Loss-DerivedConvergence~~Method.~~Time = Convergence Packet Loss/Offered Load - (Convergence Event Instant - start traffic instant) Equation 6 The Convergence Event Instant and start traffic instant SHOULD be collected by the Tester.Measurement Units: seconds Issues: None See Also: Convergence Packet~~Loss Rate-Derived Convergence Method Route-Specific Convergence Convergence Event Transition Convergence Recovery Transition 3.4.5~~Loss, ConnectivityPacket~~Sampling Interval~~Loss, Route Convergence 3.6.5. Route Loss of Connectivity PeriodDefinition: The~~interval at which the tester (test equipment) polls to make measurements~~time duration of traffic lossfor~~arriving packet flows. Discussion: At least one packet per~~a specificroute~~in~~entry following a Convergence Event until Full Convergence completion, as observed usingthe~~FIB for all routes in~~Route-Specific Loss-Derived Method. Discussion: In generalthe~~FIB MUST be offered~~Route Loss of Connectivity Period is not equalto theRoute-Specific Convergence Time. If theDUT~~within~~continues to forward traffic tothe~~Packet Sampling Interval. Metrics measured at~~Preferred Egress Interface afterthe~~Packet Sampling Interval MUST include Forwarding Rate and~~Convergence~~Packet Loss. Packet Sampling Interval can influence~~Event is applied then the Route Loss of Connectivity Period will be smaller thantheRoute-SpecificConvergence~~Graph.~~Time.This is~~particularly true when implementations complete Full Convergence in less time than~~also specificallythe~~Packet Sampling Interval.~~case after reversing a failure event.The~~Convergence Event Transition and Convergence Recovery Transition Link-State IGP Data Plane~~Route~~Convergence can become exaggerated when the Packet Sampling Interval is too long. In this condition,~~Loss of Connectivity Period may be equal tothe~~Rate-Derived~~Route- SpecificConvergence~~Method may produce~~Time, asa~~larger than actual convergence time. In such cases~~characteristic ofthe~~Loss-Derived~~Convergence~~Method may produce~~Event, traffic for all routes starts dropping instantaneously on the Convergence Event Instant. See discussion in [Po09m]. For the testcases described in [Po09m] the Route Loss of Connectivity Period is expected to bea~~more accurate result.~~single Loss Period [Ko02]. When benchmarking Route Loss of Connectivity Period, Connectivity Packet Loss is measured for each route and Equation 7 is applied for each measured route entry.The~~recommended value~~calculation is equal to Equation 3 in Section 3.6.3. Route Loss of Connectivity Period = Connectivity Packet Lossfor~~configuration~~specific route/Offered Load per route Equation 7 Route Lossof~~the Packet Sampling Interval is provided in [Po07m].~~Connectivity Period SHOULD be measured using Route- Specific Loss-Derived Method.Measurement Units: seconds Issues: None See Also:Route-SpecificConvergenceTime, Route-Specific Loss-Derived Method, ConnectivityPacket Loss~~Convergence Event Transition Convergence Recovery Transition 3.5 Benchmarks 3.5.1 Full Convergence Time~~3.6.6. Loss-Derived Loss of Connectivity PeriodDefinition: The~~amount of~~averagetime~~it takes~~duration of traffic lossfor~~Full~~all routes following aConvergence~~to occur. Discussion:~~Event untilFull Convergence~~Time can be determined~~completion, as observedusing the~~Rate-Derived Convergence Method or~~Loss-Derived~~Convergence~~Method.~~The Rate-Derived~~Discussion: In general the Loss-Derived Loss of Connectivity Period is not equal to the Loss-DerivedConvergence~~Method~~Time. If the DUT continues to forward traffic to the Preferred Egress Interface after the Convergence Eventis~~RECOMMENDED. When measuring Route-Specific~~applied then the Loss-Derived Loss of Connectivity Period will be smaller than the Loss-DerivedConvergence~~Time, there~~Time. This is also specifically the case after reversing a failure event. The Loss-Derived Loss of Connectivity Periodmay be~~conditions in which~~equal tothe~~maximum Route Specific~~Loss-DerivedConvergence Time~~can be reported~~if,asa characteristic ofthe~~Full~~Convergence~~Time. Full~~Event, traffic for all routes starts dropping instantaneously on theConvergence~~may or may not~~Event Instant. See discussion in [Po09m]. For the testcases described in [Po09m] each route's Route Loss of Connectivity Period is expected tobe~~sustained over time.~~a single Loss Period [Ko02]. When benchmarking Loss-Derived Loss of Connectivity Period, Connectivity Packet Loss is measured for all routes and Equation 8 is applied.The~~Sustained Convergence Validation Time MUST~~calculation is equal to Equation 5 in Section 3.6.4. Loss-Derived Loss of Connectivity Period = Connectivity Packet Loss for all routes/Offered Load Equation 8 Loss-Derived Loss of Connectivity Period SHOULDbe~~applied.~~measured using Loss-Derived Method. Measurement Units: seconds Issues: None See Also: Loss-Derived Convergence Time, Loss-Derived Method, Connectivity Packet Loss 3.7. Measurement Terms 3.7.1. Convergence Event Definition: The occurrence of a planned or unplanned event in the network that will result in a change in the egress interface of the Device Under Test (DUT) for routed packets. Discussion: Convergence Events include but are not limited to link loss, routing protocol session loss, router failure, configuration change, and better next-hop learned via a routing protocol.Measurement Units:~~seconds~~N/AIssues: None See Also:~~Full Convergence Rate-Derived~~Convergence~~Method Loss-Derived Convergence Method 3.5.2 First Route Convergence Time~~Event Instant 3.7.2. Packet LossDefinition: The~~amount~~numberof~~time for Convergence~~packets that should have been forwarded by a DUT under a constant Offered Load that were not forwarded due to lack of resources. Discussion:Packet Loss~~until the convergence of~~isa~~first route entry on~~modified version ofthe~~Next-Best Egress Interface,~~term "Frame Loss Rate"as~~indicated by the First Route~~defined in [Br91]. The term "Frame Loss" is intended for Ethernet Frames while "Packet Loss" is intended for IP packets. Measurement units: Number of offered packets that are not forwarded. Issues: None See Also:Convergence~~Instant. Link-State IGP Data Plane Route~~Packet Loss 3.7.3.Convergence~~Discussion:~~Packet Loss Definition:The~~First Route Convergence Time benchmarking metric can be measured when benchmarking either Full~~number of packets lost due to aConvergence~~or Route-Specific Convergence. When benchmarking~~Event untilFull~~Convergence, First Route~~Convergence~~Time can be measured~~completes,asobserved onthe~~time difference from the Convergence Event Instant and the First Route Convergence Instant, as shown with Equation 4a. (Equation 4a) First Route Convergence Time = First Route Convergence Instant - Convergence Event Instant First Route~~Next-Best Egress Interface. Discussion:Convergence~~Time should be measured at the maximum Throughput of the DUT. At least one packet per route in the FIB for all routes in the FIB MUST be offered to the DUT within the~~Packet~~Sampling Interval. Failure~~Loss is observed on the Next-Best Egress Interface. It only needsto~~achieve the First Route~~be observed forConvergence~~Instant results in a First Route~~Events that do not cause instantaneous traffic loss atConvergence~~Time benchmark~~Event Instant. Convergence Packet Loss includes packets that were lost and packets that were delayed due to buffering. The magnitude of an acceptable Forwarding Delay is a parameterof~~infinity.~~the methodology. If a maximum acceptable Forwarding Delay threshold is applied it MUST be reported.Measurement Units:~~seconds~~number of packetsIssues: None See Also:Packet Loss, Full Convergence,ConvergenceEvent, Connectivity Packet Loss 3.7.4. ConnectivityPacket Loss~~First Route Convergence Instant 3.5.3 Route-Specific Convergence Time~~Definition: The~~amount of time it takes for Route-Specific Convergence to be completed as calculated from the amount~~numberof~~Convergence Packet Loss for the flow associated~~packets lost dueto a~~specific route. Route-Specific~~Convergence~~Time can be calculated from~~Event until FullConvergencecompletes. Discussion: ConnectivityPacket Loss~~as shown with Equation 3. (Equation 3) Route-Specific Convergence Time =~~is observed on all DUT egress interfaces.Convergence~~Packets~~PacketLoss~~/ Offered Load where units are~~includespackets~~/ packets/second = seconds Link-State IGP Data Plane Route Convergence Discussion: It is possible to provide an offered load~~that~~has flows matching every route entry in the FIB~~were lostand~~benchmarking Route-Specific Convergence Time for all route entries.~~packets that were delayed due to buffering.The~~number~~magnitudeof~~flows that can be measured~~an acceptable Forwarding Delayis~~dependent upon the flow measurement capabilities~~a parameterof the~~Tester. When benchmarking Route-Specific Convergence,~~methodology. If a maximum acceptable Forwarding Delay threshold is applied it MUST be reported. Measurement Units: number of packets Issues: None See Also: Packet Loss, Route Loss of Connectivity Period, Convergence Event,Convergence Packet Loss~~is measured for specific flow(s) and Equation 3 is applied~~3.7.5. Packet Sampling Interval Definition: The interval at which the Tester (test equipment) polls to make measurementsfor~~each flow. Each flow has a single destination address matching a different~~arriving packets. Discussion: At least one packet perroute~~entry. The fastest measurable convergence time is equal to~~inthe~~time between two consecutive packets of a flow~~FIB for all routes MUST beoffered~~by~~tothe~~Tester. In practice,~~DUT withinthe~~fastest measurable convergence time is~~Packet Sampling Interval. Metrics measured atthe Packet Sampling Interval~~of~~MUST include Forwarding Rate and received packets. Packet Sampling Interval can influencethe~~Tester.~~Convergence Graph as observed with the Rate-Derived Method. This is particularly true when implementations complete Full Convergence in less time than the Packet Sampling Interval.The~~Route-Specific~~Convergence~~Time benchmarks enable minimum, maximum, average,~~Event Instantand~~median convergence time measurements to~~First Route Convergence Instant may notbe~~reported by comparing the results for~~easily identifiable andthe~~different route entries. It also enables benchmarking of convergence time when configuring~~Rate-Derived Method may producea~~priority~~larger than actual convergence time. The recommendedvalue for~~route entry(ies). Since multiple Route-Specific Convergence Times can be measured it is possible to have an array~~configurationof~~results. The format for reporting Route-Specific Convergence Time~~the Packet Sampling Interval when using the Rate-Derived Methodis provided in~~[Po07m].~~[Po09m]. For the other benchmark methods the value of the Packet Sampling Interval does not contribute to the measurement accuracy.Measurement Units: seconds Issues: None See Also:~~Convergence Event Convergence Packet Loss Route-Specific Convergence 3.5.4~~Rate-Derived Method 3.7.6.Sustained Convergence Validation Time Definition: The amount of time for which the completion of Full Convergence is maintained without additional packet loss. Discussion: The purpose of the Sustained Convergence Validation Time is to produce~~Convergence~~convergencebenchmarks protected against fluctuation in~~Throughput~~Forwarding Rateafter the completion of Full Convergence is observed. The RECOMMENDED Sustained Convergence Validation Time to be used is 5 seconds. The BMWG selected 5 seconds based upon RFC 2544~~[Ba99]~~[Br99]which recommends waiting 2 seconds for residual frames to arrive and 5 seconds for DUT restabilization.~~Link-State IGP Data Plane Route~~Measurement Units: seconds Issues: None See Also: Full Convergence, Convergence Recovery Instant 3.8. Miscellaneous Terms 3.8.1. Stale Forwarding Definition: Forwarding of traffic to route entries that no longer exist or to route entries with next-hops that are no longer preferred. Discussion: Stale Forwarding can be caused by a Convergence Event and can manifest as a "black-hole" or microloop that produces packet loss, or out-of-order packets, or delayed packets. Stale Forwarding can exist until NetworkConvergenceis completed.Measurement Units:~~seconds~~N/AIssues: None See Also:~~Full Convergence~~NetworkConvergence~~Recovery Instant 3.5.5 Reversion~~3.8.2. NestedConvergence~~Time~~EventDefinition: The~~amount~~occurrenceof~~time for the DUT to complete Full~~aConvergence~~to the Preferred Egress Interface, instead of~~Event whilethe~~Next-Best Egress Interface, upon recovery~~route table is convergingfrom apriorConvergence Event. Discussion:~~Reversion~~TheConvergence~~Time is the amount of time~~Eventsfor~~Full~~a NestedConvergence~~to the original egress interface. This is achieved by recovering~~Event MUST occur with different neighbors. A possible observationfrom~~the Convergence Event, such as restoring the failed link. Reversion~~a NestedConvergence~~Time can~~Event willbe~~measured using the Rate-Derived Convergence Method or Loss-Derived Convergence Method. The Rate-Derived Convergence Method is RECOMMENDED. It is possible to have~~the~~Reversion Convergence Time differ~~withdrawal of routesfromone neighbor whilethe~~Full Convergence Time.~~routes of another neighbor are being installed.Measurement Units:~~seconds~~N/AIssues: None See Also:~~Preferred Egress Interface~~Convergence Event~~Rate-Derived Convergence Method~~4.~~IANA Considerations This document requires no IANA considerations. 5.~~Security Considerations Documents of this type do not directly affect the security of Internet or corporate networks as long as benchmarking is not performed on devices or systems connected to production networks. Security threats and how to counter these in SIP and the media layer is discussed in RFC3261, RFC3550, and RFC3711 and various other drafts. This document attempts to formalize a set of common~~terminology~~methodologyfor benchmarking IGP convergence performance in a lab environment.~~Link-State IGP Data Plane Route Convergence~~5. IANA Considerations This document requires no IANA considerations.6. Acknowledgements Thanks to Sue Hares, Al Morton, Kevin Dubray, Ron Bonica, David Ward,~~Kris Michielsen~~Peter De Vriendtand the BMWG for their contributions to this work. 7. References~~7.1~~7.1.Normative References~~[Ba91]~~[Br91]Bradner,~~S.~~S.,"Benchmarking~~Terminology~~terminologyfor~~Network Interconnection Devices", RFC1242,~~network interconnection devices", RFC 1242,July 1991.~~[Ba99]~~[Br97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [Br99]Bradner, S. andJ.McQuaid,~~J.,~~"Benchmarking Methodology for Network Interconnect Devices", RFC 2544, March 1999.~~[Br97] Bradner, S., "Key words for use in RFCs to Indicate~~[Ca90] Callon, R., "Use of OSI IS-IS for~~Routing~~routingin TCP/IP and~~Dual Environments",~~dual environments",RFC 1195, December 1990.[Co08] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [Ho08] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. [Ko02] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002.[Ma98] Mandeville, R., "Benchmarking Terminology for LAN Switching Devices", RFC 2285, February 1998.~~[Mo98] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.~~[Mo06] Morton, A.,~~et al,~~Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser,"Packet Reordering Metrics", RFC 4737, November 2006.[Mo98] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.[Po06] Poretsky, S.,~~et al.,~~Perser, J., Erramilli, S., and S. Khurana,"Terminology for Benchmarking Network-layer Traffic Control Mechanisms", RFC 4689,~~November~~October2006.~~[Po07a]~~[Po09a]Poretsky, S.,~~"Benchmarking Applicability~~"ConsiderationsforBenchmarkingLink-State IGP Data Plane Route Convergence",~~draft-ietf-bmwg-igp-dataplane-conv-app-17, work~~draft-ietf-bmwg-igp-dataplane-conv-app-17 (workin~~progress,~~progress),March 2009.~~[Po07m]~~[Po09m]Poretsky, S. andB.Imhoff,~~B.,~~"Benchmarking Methodology for Link-State IGP Data Plane Route Convergence",~~draft-ietf-bmwg-igp-dataplane-conv-meth-17, work~~draft-ietf-bmwg-igp-dataplane-conv-meth-18 (workin~~progress, March~~progress), July2009.~~7.2~~7.2.Informative References [Ca01]~~S.~~Casner,~~C.~~S.,Alaettinoglu,C.,and C. Kuan, "A Fine-Grained View of High Performance Networking", NANOG 22, June 2001. [Ci03]~~L.~~Ciavattone,~~A.~~L.,Morton,A.,and G. Ramachandran, "Standardized Active Measurements on a Tier 1 IP Backbone", IEEE Communications~~Magazine, pp90-97,~~Magazine p90-97,May 2003.~~Link-State IGP Data Plane Route Convergence 8. Author's Address~~Authors' AddressesScott Poretsky Allot Communications 67 South Bedford Street, Suite 400 Burlington, MA 01803 USA Phone: + 1 508 309 2179 Email: sporetsky@allot.com Brent Imhoff Juniper Networks 1194 North Mathilda Ave Sunnyvale, CA 94089 USA Phone: + 1 314 378 2571~~EMail:~~Email:bimhoff@planetspork.comKris Michielsen Cisco Systems 6A De Kleetlaan Diegem, BRABANT 1831 Belgium Email: kmichiel@cisco.com