[bmwg] RE: IGP Convergence

[[e-mail]]

Diego and BMWG-ers,
 
Excellent comments below.  
1.                Methodology doc, page 6: it was a bit confusing if they
were talking about reporting the timer values of the DUT or the emulated
devices.  One can assume it's the DUT but a word or two could make this
clearer.

 

2.                Methodology doc, page 6-8: in the test procedure for
4.1.1, steps 4 and 7 mention SONET specifically.  Unless these test cases
are only for SONET they should make this a more generic statement for
removing the layer-1 connection (e.g. disconnect an Ethernet cable).  The
same issue appears in the other test cases.

 

3.                Methodology doc, page 10:  test case 4.4 is missing step
5.

 
In addition,  the following notes were made in the IETF-62 meeting minutes:
 
(methodology)

- There is an IESG mandate to handle IPv6 on par with IPv4

- There should be a test case with a smaller number of routes (to vet
config)

- Multiple ingress interfaces must share the Forwarding Capacity,

otherwise congestion will result

- Establish the Maximum Offered Load with a test up-front to set the
baseline

To address these I propose the following changes

I. Add two references:

      [5] Bradner, S., "Benchmarking Terminology for Network Interconnection

            Devices", RFC 1242, IETF, July 1991.

      [6] Bradner, S. and McQuaid, J., "Benchmarking Methodology for 
            Network Interconnect Devices", RFC 2544, IETF, March 1999.
  

II. Modify paragraphs 3.2.6, 3.2.7, and 3.3 to read as follows:

  3.2.6 Interface Types
   All test cases in this methodology document may be executed with
   any interface type.  All interfaces MUST be the same media and 
   Throughout [5,6] for each test case.  Media and protocols MUST 
   be configured for minimum failure detection delay to minimize 
   the contribution to the measured Convergence time.  For example, 
   configure SONET with  minimum carrier-loss-delay or Bi-directional 
   Forwarding Detection (BFD) [7].

   3.2.7 Offered Load
   The offered Load MUST be the Throughput of the device as defined 
   in [5] and benchmarked in [6] at a fixed packet size.  The packet 
   size is selectable and MUST be recorded.  The Throughput MUST be 
   measured at the Preferred Egress Interface and the Next-Best 
   Egress Interface.  The duration of offered load MUST be greater 
   than the convergence time.  The destination addresses for the 
   offered load MUST be distributed such that all routes are matched.  
   This enables Full Convergence [2] to be observed.

  3.3 Reporting Format
   For each test case, it is recommended that the following reporting 
   format be completed:
 
        Parameter                                 Units
        ---------                                 -----
    IGP                                       (ISIS or OSPF)
    Interface Type                            (GigE, POS, ATM, etc.)
    Packet Size offered to DUT                bytes
    IGP Routes advertised to DUT              number of IGP routes
    Packet Sampling Interval on Tester        seconds or milliseconds
    IGP Timer Values configured on DUT
         SONET Failure Indication Delay    seconds or milliseconds
            IGP Hello Timer                   seconds or milliseconds
            IGP Dead-Interval                 seconds or milliseconds
            LSA Generation Delay              seconds or milliseconds
            LSA Flood Packet Pacing           seconds or milliseconds
            LSA Retransmission Packet Pacing  seconds or milliseconds
            SPF Delay                         seconds or milliseconds
        Benchmarks 
         Rate-Derived Convergence Time     seconds or milliseconds
         Loss-Derived Convergence Time     seconds or milliseconds
         Restoration Convergence Time      seconds or milliseconds
 

III. In all procedures paragraph 2 changes to:

 2. Send offered load at measured Throughput with fixed packet size 
           to destinations matching all IGP routes from Tester to DUT on 
           Ingress Interface [2].

instead of:

 2. Send traffic at maximum forwarding rate to destinations 
           matching all IGP routes from Tester to DUT on Ingress Interface
[2].

IV. In all procedures use of 'SONET' replace with 'link'

V. Introduction includes statement: "These methodologies apply to IPv4 and
IPv6 traffic 
   as well as IPv4 and IPv6 IGPs."

Please send me any comments to these proposed changes.

Scott

-----Original Message-----
From: Diego Dugatkin [mailto:[e-mail]]
Sent: Friday, April 29, 2005 8:23 PM
To: [e-mail]; [e-mail]
Cc: Al Morton; Kevin Dubray
Subject: IGP Convergence



Please find the following feedback on the IGP Convergence drafts:

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth-
05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-meth
-05.txt> 

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term-
05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-term
-05.txt> 

http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-0
5.txt
<http://www.ietf.org/internet-drafts/draft-ietf-bmwg-igp-dataplane-conv-app-
05.txt> 

 

Overall, we find these drafts solid and have only a few small comments:

 

1.                Methodology doc, page 6: it was a bit confusing if they
were talking about reporting the timer values of the DUT or the emulated
devices.  One can assume it's the DUT but a word or two could make this
clearer.

 

2.                Methodology doc, page 6-8: in the test procedure for
4.1.1, steps 4 and 7 mention SONET specifically.  Unless these test cases
are only for SONET they should make this a more generic statement for
removing the layer-1 connection (e.g. disconnect an Ethernet cable).  The
same issue appears in the other test cases.

 

3.                Methodology doc, page 10:  test case 4.4 is missing step
5.

 

(I have also sent other comments directly to Scott, discussing precision of
the convergence time measurements based on the proposed methodology, and a
potential modification to that.)

 

 

Regards,

 

Dr. Diego Dugatkin

Principal Technologist

Ixia

26601 West Agoura Road

Calabasas, CA 91302 - U.S.A.

www.ixiacom.com <http://www.ixiacom.com> 

Tel. direct:  [phone]

 

_______________________________________________
bmwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/bmwg