 1/draftietfbmwgigpdataplaneconvterm04.txt 20060204 22:52:40.000000000 +0100
+++ 2/draftietfbmwgigpdataplaneconvterm05.txt 20060204 22:52:41.000000000 +0100
@@ 1,25 +1,26 @@
+
Network Working Group
INTERNETDRAFT
 Expires in: April 2005
+ Expires in: October 2005
Scott Poretsky
Quarry Technologies
Brent Imhoff
LightCore
 October 2004
+ February 2005
Terminology for Benchmarking
IGP Data Plane Route Convergence

+
Intellectual Property Rights (IPR) statement:
By submitting this InternetDraft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, or
will be disclosed, and any of which I become aware will be disclosed,
in accordance with RFC 3668.
Status of this Memo
This document is an InternetDraft and is in full conformance with
@@ 65,41 +66,43 @@
3.5 Convergence Packet Loss...................................5
3.6 Convergence Event Instant.................................6
3.7 Convergence Recovery Instant..............................6
3.8 RateDerived Convergence Time.............................7
3.9 Convergence Event Transition..............................7
3.10 Convergence Recovery Transition..........................8
3.11 LossDerived Convergence Time............................8
3.12 Sustained Forwarding Convergence Time....................9
3.13 Restoration Convergence Time.............................9
3.14 Packet Sampling Interval.................................10
 3.15 Local Interface..........................................10
+ 3.15 Local Interface..........................................11
3.16 Neighbor Interface.......................................11
 3.17 Remote Interface........................................11
 3.18 Preferred Egress Interface...............................11
 3.19 NextBest Egress Interface..............................12
 3.20 Stale Forwarding.........................................12
+ 3.17 Remote Interface.........................................11
+ 3.18 Preferred Egress Interface...............................12
+ 3.19 NextBest Egress Interface...............................12
+ 3.20 Stale Forwarding.........................................13
+ 3.21 Nested Convergence Events................................13
4. Security Considerations.......................................13
 5. References....................................................13
 6. Author's Address..............................................13
+ 5. Normative References..........................................14
+ 6. Author's Address..............................................14
1. Introduction
This draft describes the terminology for benchmarking IGP Route
Convergence. The motivation and applicability for this
benchmarking is provided in [1]. The methodology to be used for
this benchmarking is described in [2]. The methodology and
terminology to be used for benchmarking Route Convergence can be
applied to any linkstate IGP such as ISIS [3] and OSPF [4]. The
data plane is measured to obtain blackbox (externally observable)
convergence benchmarking metrics. The purpose of this document is
to introduce new terms required to complete execution of the IGP
 Route Convergence Methodology [2].
+ Route Convergence Methodology [2]. These terms apply to IPv4 and
+ IPv6 traffic as well as IPv4 and IPv6 IGPs.
An example of Route Convergence as observed 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 Xaxis is on the far
right of the graph. The components of the graph and metrics are
defined in the Term Definitions section.
IGP Data Plane Route Convergence
Convergence Convergence
@@ 110,29 +113,29 @@
\ Loss /<Convergence
Convergence>\ / Event Transition
Recovery Transition \ /
\_____/<Packet Loss
Xaxis = Time
Yaxis = Forwarding Rate
Figure 1. Convergence Graph
2. Existing definitions
 For the sake of clarity and continuity this RFC adopts the template
 for definitions set out in Section 2 of RFC 1242. Definitions are
 indexed and grouped together in sections for ease of reference.
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 RFC 2119.
+ "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 Convergence Event
Definition:
The occurrence of a planned or unplanned action in the network
that results in a change in the egress interface of the DUT for
routed packets.
Discussion:
Convergence Events include link loss, routing protocol session
loss, router failure, configuration change, and better nexthop
@@ 195,25 +198,26 @@
Route Convergence
Stale Forwarding
IGP Data Plane Route Convergence
3.4 Full Convergence
Definition:
Route Convergence for an entire FIB.
Discussion:
When benchmarking convergence it is useful to measure
 the time to converge an entire route table. For example,

 a Convergence Event can be produced for an OSPF table of 5000
 routes so that the time to converge routes 1 through 5000
 is measured.
+ the time to converge an entire FIB. For example,
+ a Convergence Event can be produced for an OSPF table of
+ 5000 routes so that the time to converge routes 1 through
+ 5000 is measured. Full Convergence is externally observable
+ from the data plane when the forwarding rate on the NextBest
+ Egress Interface equals the offered load.
Measurement Units:
N/A
Issues:
None
See Also:
Network Convergence
Route Convergence
@@ 263,55 +267,54 @@
See Also:
Convergence Event
Convergence Packet Loss
Convergence Recovery Instant
3.7 Convergence Recovery Instant
Definition:
The time instant that Full Convergence is measured
 and maintained for at least an additional five seconds.
+ and then maintained for an interval of duration equal to
+ the Sustained Forwarding Convergence Time
Discussion:
Convergence Recovery Instant is measurable from the data
plane as the precise time that the device under test
 achieves Full Convergence. Convergence Recovery Instant
 is externally observable from the data plane when the
 forwarding rate on the NextBest Egress Interface equals
 the offered rate.
+ achieves Full Convergence.
Measurement Units:
hh:mm:ss:uuu
Issues:
None
See Also:
+ Sustained Forwarding Convergence Time
Convergence Packet Loss
Convergence Event Instant
IGP Data Plane Route Convergence
3.8 RateDerived Convergence Time
Definition:
 The amount of time for Convergence Packet Loss to
 persist upon occurrence of a Convergence Event until
 occurrence of Route Convergence.
+ The amount of time for Convergence Packet Loss to persist upon
+ occurrence of a Convergence Event until occurrence of Route
+ Convergence.
 Discussion:
RateDerived Convergence Time can be measured as the time
difference from the Convergence Event Instant to the
Convergence Recovery Instant, as shown with Equation 1.
(eq 1) RateDerived Convergence Time =
Convergence Recovery Instant  Convergence Event Instant.
+ Discussion:
RateDerived Convergence Time should be measured at the maximum
forwarding rate. Failure to achieve Full Convergence results in
a RateDerived Convergence Time benchmark of infinity.
Measurement Units:
seconds/milliseconds
Issues:
None
@@ 365,98 +368,106 @@
Full Convergence
RateDerived Convergence Time
Convergence Packet Loss
Convergence Event Transition
3.11 LossDerived Convergence Time
Definition:
The amount of time it takes for Route Convergence to
to be achieved as calculated from the Convergence Packet
 Loss.

 Discussion:
 LossDerived Convergence Time can be calculated from
 Convergence Packet Loss that occurs due to a Convergence Event
 and Route Convergence, as shown with Equation 2.
+ Loss. LossDerived Convergence Time can be calculated
+ from Convergence Packet Loss that occurs due to a
+ Convergence Event and Route Convergence.as shown with
+ Equation 2.
(eq 2) LossDerived Convergence Time =
 Convergence Packets Loss / Forwarding Rate
+ Convergence Packets Loss / Offered Load
NOTE: Units for this measurement are
packets / packets/second = seconds
 Measurement Units:
 seconds/milliseconds

 Issues:
+ Discussion:
LossDerived Convergence Time gives a better than
actual result when converging many routes simultaneously.
RateDerived Convergence Time takes the Convergence Recovery
Transition into account, but LossDerived Convergence Time
ignores the Route Convergence Recovery Transition because
it is obtained from the measured Convergence Packet Loss.
Ideally, the Convergence Event Transition and Convergence
 IGP Data Plane Route Convergence

Recovery Transition are instantaneous so that the
RateDerived Convergence Time = LossDerived Convergence Time.
However, router implementations are less than ideal.
For these reasons the preferred reporting benchmark for IGP
Route Convergence is the RateDerived Convergence Time.
+
+ IGP Data Plane Route Convergence
+
Guidelines for reporting LossDerived Convergence Time are
provided in [2].
+ Measurement Units:
+ seconds/milliseconds
+
+ Issues:
+ None
+
See Also:
Route Convergence
Convergence Packet Loss
RateDerived Convergence Time
Convergence Event Transition
Convergence Recovery Transition
3.12 Sustained Forwarding Convergence Time
Definition:
 The amount of time for Route Convergence to be achieved for
 cases in which there is no packet loss.
+ The amount of time for which Full Convergence is maintained without
+ additional packet loss.
Discussion:
 Sustained Forwarding Convergence Time is the IGP Route Convergence
 benchmark to be used for Convergence Events that produce
 a change in nexthop without packet loss.
+ The purpose of the Sustained Forwarding Convergence Time is to produce
+ Convergence Time benchmarks protected against fluctuation in Forwarding
+ Rate after Full Convergence is observed. The Sustained Forwarding
+ Convergence Time to be used is calculated as shown in Equation 3.
+
+ (eq 3)
+ Sustained Forwarding Convergence Time =
+ 5 x (# routes in FIB) / (Offered Load)
+
+ for which at least one packet per destination MUST be received at
+ the DUT.
Measurement Units:
 seconds/milliseconds
+ seconds or milliseconds
 Issues:
 None
+ Issues: None
See Also:
 Route Convergence
 RateDerived Convergence Time
 LossDerived Convergence Time
+ Full Convergence
+ Convergence Recovery Instant
3.13 Restoration Convergence Time
Definition:
The amount of time for the router under test to restore
traffic to the original outbound port after recovery from
a Convergence Event.
+ IGP Data Plane Route Convergence
+
Discussion:
Restoration Convergence Time is the amount of time to
Converge back to the original outbound port. This is achieved
by recovering from the Convergence Event, such as restoring
the failed link. Restoration Convergence Time is measured
using the RateDerived Convergence Time calculation technique,
as provided in Equation 1. It is possible, but not desired
 IGP Data Plane Route Convergence

to have the Restoration Convergence Time differ from the
RateDerived Convergence Time.
Measurement Units:
seconds or milliseconds
Issues:
None
See Also:
@@ 482,31 +493,31 @@
Transition and Convergence Recovery Transition can become
exaggerated when the Packet Sampling Interval is too long.
This will produce a larger than actual RateDerived
Convergence Time. The recommended value for configuration
of the Packet Sampling Interval is provided in [2].
See Also:
Convergence Packet Loss
Convergence Event Transition
Convergence Recovery Transition
+ IGP Data Plane Route Convergence
3.15 Local Interface
Definition:
An interface on the DUT.
Discussion:
None
Measurement Units:
N/A
 IGP Data Plane Route Convergence
Issues:
None
See Also:
Neighbor Interface
Remote Interface
3.16 Neighbor Interface
@@ 534,101 +545,124 @@
connected to any interface on the DUT.
Discussion:
None
Measurement Units:
N/A
Issues:
None
+ IGP Data Plane Route Convergence
See Also:
Local Interface
Neighbor Interface
3.18 Preferred Egress Interface
Definition:
The outbound interface from the DUT for traffic routed to the
preferred nexthop.
 IGP Data Plane Route Convergence

Discussion:
Preferred Egress Interface is the egress interface prior to
a Convergence Event
Measurement Units:
N/A
Issues:
None
See Also:
NextBest Egress Interface
3.19 NextBest Egress Interface
Definition:
The outbound interface from the DUT for traffic routed to the
 secondbest nexthop.
+ secondbest nexthop. It is the same media type and link speed
+ as the Preferred Egress Interface
Discussion:
NextBest Egress Interface is the egress interface after
a Convergence Event.
Measurement Units:
N/A
Issues:
None
See Also:
Preferred Egress Interface
+ IGP Data Plane Route Convergence
3.20 Stale Forwarding
Definition:
Forwarding of traffic to route entries that no longer exist
or to route entries with nexthops that are no longer preferred.
Discussion:
Stale Forwarding can be caused by a Convergence Event and is
also known as a "blackhole" since it may produce packet loss.
Stale Forwarding exists until Network Convergence is achieved.
Measurement Units:
N/A
Issues:
None
See Also:
Network Convergence
 IGP Data Plane Route Convergence
+
+ 3.21 Nested Convergence Events
+ Definition:
+ The occurence of Convergence Event while the route table
+ is converging from a prior Convergence Event.
+
+ Discussion:
+ The Convergence Events for a Nested Convergence Events
+ MUST occur with different neighbors. A common
+ observation from a Nested Convergence Event will be
+ the withdrawal of routes from one neighbor while the
+ routes of another neighbor are being installed.
+
+ Measurement Units:
+ N/A
+
+ Issues:
+ None
+
+ See Also:
+ Convergence Event
4. 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 operating
networks.
 5. References
+ IGP Data Plane Route Convergence
+
+ 5. Normative References
[1] Poretsky, S., "Benchmarking Applicability for IGP Data Plane
 Route Convergence", draftietfbmwgigpdataplaneconvapp04,
 work in progress, October 2004.
+ Route Convergence", draftietfbmwgigpdataplaneconvapp05,
+ work in progress, February 2005.
[2] Poretsky, S., "Benchmarking Methodology for IGP Data Plane
 Route Convergence", draftietfbmwgigpdataplaneconvmeth04,
 work in progress, October 2004.
+ Route Convergence", draftietfbmwgigpdataplaneconvmeth05,
+ work in progress, February 2005.
[3] Callon, R., "Use of OSI ISIS for Routing in TCP/IP and Dual
Environments", RFC 1195, December 1990.
[4] Moy, J., "OSPF Version 2", RFC 2328, IETF, April 1998.
[5] S. Casner, C. Alaettinoglu, and C. Kuan, "A FineGrained View
of High Performance Networking", NANOG 22, May 2001.
[6] L. Ciavattone, A. Morton, and G. Ramachandran, "Standardized
@@ 641,32 +675,33 @@
Quarry Technologies
8 New England Executive Park
Burlington, MA 01803
USA
Phone: + 1 781 395 5090
EMail: sporetsky@quarrytech.com
Brent Imhoff
USA
EMail: bimhoff@planetspork.com
 IGP Data Plane Route Convergence
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any Intel
lectual Property Rights or other rights that might be claimed to pertain
to the implementation or use of the technology described in this docu
ment or the extent to which any license under such rights might or might
not be available; nor does it represent that it has made any independent
effort to identify any such rights. Information on the procedures with
respect to rights in RFC documents can be found in BCP 78 and BCP 79.
+ IGP Data Plane Route Convergence
+
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can be
obtained from the IETF online IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this stan
@@ 677,13 +712,13 @@
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR
IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA
TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject to
+Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.