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

From: "Robert Holley \(rholley\)" <[email-masked]>
Date: Tue, 3 Jul 2007 17:34:33 -0400

Rajiv,

I've forwarded this on to Bob Thomas, somehow, it was mis-addressed to
myself.

Regards
Bob Holley
============================================
Robert Holley
US AS Network Infrastructure
Cisco Systems
7025 Kit Creek Road.
Research Triangle Park, NC 27709
Phone:  +1 919-392-2359
Pager:   +1 800-796-7363 pin 100-9187
============================================   

> -----Original Message-----
> From: Rajiv Papneja [mailto:[email-masked]] 
> Sent: Tuesday, July 03, 2007 12:13 PM
> To: Bob Thomas (rhthomas)
> Cc: [email-masked]
> Subject: RE: [bmwg] draft-karthik-bmwg-ldp-convergence-meth-00.txt
> 
> Hello Bob,
> 
>  
> 
> Apologies for not responding to your message earlier.  As we 
> were updating the latest version of the draft, we came across 
> this message and noticed that we have not yet responded to 
> your important comments. Please see below the responses in 
> line.  We will try to address these in the next version shortly 
> 
>  
> 
> Regards,
> 
> Rajiv
> 
>  
> 
> > 
> 
> > -----Original Message-----
> 
> > From: Bob Thomas (rhthomas) [mailto:[email-masked]]
> 
> > Sent: Wednesday, March 14, 2007 8:20 AM
> 
> > To: [email-masked]
> 
> > Subject: [bmwg] draft-karthik-bmwg-ldp-convergence-meth-00.txt
> 
> > 
> 
> > 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.
> 
> [rp] Yes, we can clarify this in the next version of the draft. 
> 
> > 
> 
> >     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.
> 
> [rp] Will make a point to define the DUT clearly.
> 
> > 
> 
> > --------
> 
> > 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.
> 
> [rp] Yes, we will include BFD in the meth-01 that we plan to 
> submit soon
> 
> > 
> 
> > --------
> 
> > 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.
> 
> [rp] We can definitely consider default settings, wherever 
> recommended by the LDP specs. If vendors support different 
> default values it could be confusing. We can try to add a 
> combination, use default values, and ensure all nodes in the 
> setup are configured to the same default values.
> 
> > 
> 
> > --------
> 
> > 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.
> 
> [rp] We will try to address it to increase more granularity 
> and better accuracy for convergence.
> 
>  
> 
> > 
> 
> > --------
> 
> > - 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.
> 
> [rp] We can have this topology defined specifically for 
> convergence measurements when parallel links are present, and 
> use 4.2 specifically for link failure convergence times.
> 
> > 
> 
> > --------
> 
> > - 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.
> 
> [rp]  "Best FEC" implies a FEC that an LSR prefers and 
> installs (over other identical FECs from different peers that 
> are not preferred for various reasons). For example Consider 
> an LSR receiving a FEC from 3 peers for the same prefix (or 
> host) w.x.y.z/32. Obviously if the IGP metric is different 
> for these 3 next hops, only one qualifies as the best FEC. Do 
> you agree with this?
> 
>  
> 
> > 
> 
> > 
> 
> >        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.
> 
> [rp] We will try to address this. 
> 
> > 
> 
> > _______________________________________________
> 
> > bmwg mailing list
> 
> > [email-masked]
> 
> > https://www1.ietf.org/mailman/listinfo/bmwg
> 
> > 
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 

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