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

From: "Rajiv Papneja" <[email-masked]>
Date: Tue, 3 Jul 2007 12:12:51 -0400

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