[bmwg] Document Action: 'Benchmarking Methodology for Link-State IGP Data Plane Route Convergence' to Informational RFC (draft-ietf-bmwg-igp-dataplane-conv-meth-23.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'Benchmarking Methodology for Link-State IGP Data Plane Route
   Convergence'
  (draft-ietf-bmwg-igp-dataplane-conv-meth-23.txt) as an Informational
RFC

This document is the product of the Benchmarking Methodology Working
Group.

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-bmwg-igp-dataplane-conv-meth/




All BMWG RFCs are Informational, but they are implemented by
test equipment vendors and cited in trade publications and
advertisements.

Technical Summary


This set of memos describes the process for benchmarking IGP
Route Convergence as described in the Applicability memo.
This approach measures convergence time in the dataplane,
and treats the Device Under Test as a Black Box.
The methodology and terminology memos define the metrics and
process for benchmarking route convergence that can be applied
to any link-state IGP such as ISIS and OSPF.


WG Summary

The drafts received extensive comment and review since their
initial acceptance on the WG charter in 2003.
Many active WG members affirmed that this set of drafts
were ready for publication (WGLC in October, 2005).
There was a subsequent cross-area review that resulted in
additional minor revisions, discussed and agreed by the WG.


Protocol Summary

These methods have been performed in at least one lab,
and review comments were posted based on that experience.
Several test equipment vendors commented actively during the WG
development.

RFC EDITOR NOTES

Section 1.2

OLD

The contribution of each of these factors listed above will vary with each 
router vendors' 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 in hardware.

NEW

The contribution of each of these factors listed above will vary with each 
router vendors' 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Section 7

OLD
For each test case, it is RECOMMENDED that the reporting tables below 
be completed and all time values SHOULD be reported with 
a sufficiently high resolution.

NEW
For each test case, it is RECOMMENDED that the reporting tables below 
be completed and all time values SHOULD be reported with 
a sufficiently high resolution (fractions of a second sufficient to 
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
distinguish significant differences between measured values).
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^