Subject: [bmwg] draft-karthik-bmwg-ldp-convergence-meth-00.txt

From: "Bob Thomas \(rhthomas\)" <[email-masked]>
Date: Wed, 14 Mar 2007 08:19:48 -0400

I think benchmarking LDP performance is important and I support the
effort to define a standard set of benchmarking scenarios for LDP.

Below are a few comments on details in
draft-karthik-bmwg-ldp-convergence-meth-00.txt.

Bob

--------
Page 4, Sec 3.1

    FEC rerouting, or LDP route calculation is triggered by link or node

#bt: LDP doesn't calculate routes; LDP sets up LSP's for FECs
    (prefixes) based on the IGP's routes.

    failures downstream of the DUT that impact the network stability: 

#bt: Link up and node up also causes LDP to change the LSP's for
prefixes.
     It might be useful (though perhaps less important) to measure
     traffic drops when the next hops for a large set of prefixes
change.

#bt: DUT (device under test?) should be defined here.

--------
Page 4, Sec 3.2         

    3.2. Failure Detection [LDP-TERM] 

    Local failures can be detected via SONET failure with directly 
    connected LSR.  Failure detection may vary with the type of alarm - 
    LOS, AIS, or RDI. Failures on Ethernet links such as Gigabit
Ethernet 
    rely upon Layer 3 signaling indication for failure.   

#bt: Might want to mention BFD as a L3 failure detection
     mechanism in this section.

--------
Page 5, Sec 3.6

    There are some timers that will impact the measured LDP Convergence

    time. The following timers should be configured to the minimum value

    prior to beginning execution of the test cases: 

#bt: For a protocol such as LDP which has default values for
     timers, it is probably worth measuring behavior with the
     default timer settings in addition to other timer values.
     Also note that setting timers to their min values doesn't
     always guarantee fastest convergence.
      
--------
Page 6, Sec 3.8

    3.8. Traffic generation 

    It is suggested that at least 3 traffic streams be configured using
a 
    traffic generator. In order to monitor the DUT performance for 
    recovery times a set of route prefixes should be advertised before 
    traffic is sent. The traffic should be configured to be sent to
these 
    routes.  

    A typical example would be configuring the traffic generator to send

    the traffic to the first and last of the advertised routes. Also In 
    order to have a good understanding of the performance behavior one 
    may choose to send the traffic to the route, lying at the middle of 
    the advertised routes. For example, if 100 routes are advertised,
the 
    user should send traffic to route prefix number 1, route prefix    
    number 50 and to last route prefix advertised, which is 100 in this 
    example. It is recommended that the traffic is not generated in 
    round-robin fashion to each of the prefixes. 

#bt: It may well not be the case that prefix 1, N/2 and N are
     the same for every implementation.  That is, the order of
     IGP convergence may not be the same for every implementation.
     In addition, the order of LDP convergence may not be the
     same either.  One way of dealing with this is to measure
     the order of LDP convergence for an implementation, and
     then determine prefix 1, N/2 and N based on that.

#bt: Also, more than 3 traffic streams would be better; say 10.

--------
- Page 6, Sec 4.1

    4.1. Topology for Single NextHop FECs (Link Failure) 

          --------   A  --------
      TG-|Ingress |----| Egress |-TA 
         |  DUT   |----|  Node  | 
          --------   B  -------- 
     
        A -> Preferred egress interface 
        B -> Next-best egress interface 
     
        Figure 1: Topology for Single NextHop FECs (Link Failure) 

#bt: I think the above is not the best topology for testing link
     failure.  I think the Section 4.2 topology where link A is
     failed is better.

#bt: If there is interest in the above topology for link failure,
     I think it is also quite important that the Section 4.2
     topology where link A is failed be included as part of the
     link failure measurements.

     The point here is that the 4.1 topology and the 4.2 topology
     where link A is failed measure different things and I would
     expect different results.  When I think of a link failure
     test I think of 4.2 where A is failed.  I think of 4.1 as a
     different case where 1 of a set of parallel links fail.

#bt: Also, TG (test generator) and TA (test analyzer) should be
     defined in this section.
        
--------
- Page 7, Sec 5

 5. Test Methodology 

    The procedure described here can apply to all the convergence 
    benchmarking cases.  

       Objective 

       To benchmark the LDP Data Plane Convergence time as seen on the 
    DUT when a Convergence event occurs resulting in the current best
FEC 
    is not reachable anymore.  

#bt: Not sure what is meant by "best FEC" in this context.

       Test Setup 

         - The DUT will have 1 interface connected to the traffic 
           generator. 
         - The DUT will also be connected to a downstream node over 2 
           parallel interfaces. 
         - The downstream neighbor will be connected to a traffic 
           analyzer 

#bt: This seems to describe the 4.1 topology/test; there doesn't
     seem to be a discussion of the the 4.2 topology/test in this
     section.

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