Subject: RE: [bmwg] Updates on LDP Convergence benchmarking

From: "Andrey Kiselev \(ankisele\)" <[email-masked]>
Date: Sat, 10 Mar 2007 01:46:26 -0500

Hi Rajiv and LDP convergence benchmarking team,
 
I have a few more questions/comments to LDP convergence methodology
draft. Let me go page by page.
 
1. Dates on top of the title page need to be updated. Currently they
are:   "Expires: February 2007" and "September, 2006"

2. page 3, last paragraph of Introduction: "Future versions of this
document will include ECMP benchmarks, LDP targeted peers and
correlated failure scenarios" 
Are you guys have anything in place already? I could probably contribute
regarding LDP targeted peers, as I recently worked with this feature.
 
3. page 4, Convergence events: I suggest to add downstream node failure
(power cycle) to this list. 
 
4. page 4. Failure Detection: "Failures on Ethernet links such as
Gigabit Ethernet rely upon Layer 3 signaling indication for failure."
 - Not sure if this statement is always true. For example, BFD does not
have to use Layer 3 (IP) signaling. BFD-over-Ethernet between two
switches will use Layer 2 instead.
 
5. page 5, BGP configuration: Do you mean that installed/flapping BGP
routes will take extra resources from DUT (memory, CPU power)? Or what
is BGP role in this scenario otherwise? I would add some clarification
to this paragraph. 
 
6. page 6, Traffic generation: "It is recommended that the traffic is
not generated in round-robin fashion to each of the prefixes". 
This may be difficult to achieve with one TG interface. I would use 3 TG
interfaces in this case - one per stream for better accuracy. Or use
traffic rate high enough to neglect round-robbin effect. Either way,
that should be explained.
 
7. page 6: I would explain TA and TG abbreviations under the picture
just for the sake of completeness.
 
8. page 7, Figure 2: TA link is missing on the picture
 
9. page 7, Test Methodology: Are you covering both Single Nexthop FECs
and Multi Next Hop FECs cases with the same procedure? If so, Test Setup
and Test Configuration should not mention 2 parallel interfaces to a
downstream node, as used in Single Nexthop case. It may be easier to
include separate Test setup/Test Configuration for these two cases.

Thanks,
 
Andrey
 
________________________________

From: Rajiv Papneja [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 3:31 PM
To: [email-masked]
Cc: [email-masked]
Subject: [bmwg] Updates on LDP Convergence benchmarking

Dear BMWG-ers,

We as a LDP convergence benchmarking author team would like to seek
input from the group on the updated terminology document, and the new
methodology document that we submitted recently to the BMWG. We look
forward to your comments on both the drafts. 

1. draft-eriksson-ldp-convergence-term-04.txt
(http://www.ietf.org/internet-drafts/draft-eriksson-ldp-convergence-term
-04.txt)

	a.	Minor editorial changes 
	b.	Added new term - LDP Advertisement Type 

2.	 LDP convergence methodology
(http://www.ietf.org/internet-drafts/draft-karthik-bmwg-ldp-convergence-
meth-00.txt) 

	a.	Submitted version 00 with preliminary test cases, more
to be added as we progress 
	b.	Draft to compliment the terminology document 
	c.	Intent to produce a formal proposal after initial review

     Thank you,

      LDP convergence benchmarking team

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

---

From: "Rajiv Papneja" <[email-masked]>
Date: Mon, 12 Mar 2007 11:47:30 -0400

Dear Andrey,

Thank you so much for your detailed feedback. I am glad to see that you have
thoroughly reviewed the draft, and have significant interest in the work
item.

Please see below our response.

Regards,

  Rajiv

  _____  

From: Andrey Kiselev (ankisele) [mailto:[email-masked]] 
Sent: Saturday, March 10, 2007 1:46 AM
To: Rajiv Papneja; [email-masked]
Cc: [email-masked]
Subject: RE: [bmwg] Updates on LDP Convergence benchmarking

I have a few more questions/comments to LDP convergence methodology draft.
Let me go page by page.

1. Dates on top of the title page need to be updated. Currently they are:
"Expires: February 2007" and "September, 2006"

[rp] I agree, that was probably an overlook on our part.

2. page 3, last paragraph of Introduction: "Future versions of this document
will include ECMP benchmarks, LDP targeted peers and  correlated failure
scenarios" 

[rp] We have a few scenarios in mind, but your contribution is greatly
appreciated. Please suggest that section, and we can try to include it.

[rp] Agree, this is an important failure scenario, provided that these days
carriers are very interested in the time taken by a node to resume  

all the services from cold start. 

4. page 4. Failure Detection: "Failures on Ethernet links such as Gigabit
Ethernet rely upon Layer 3 signaling indication for failure."

 - Not sure if this statement is always true. For example, BFD does not have
to use Layer 3 (IP) signaling. BFD-over-Ethernet between two switches will
use Layer 2 instead.

[rp] I agree, we can address this.

5. page 5, BGP configuration: Do you mean that installed/flapping BGP routes
will take extra resources from DUT (memory, CPU power)? Or what is BGP role
in this scenario otherwise? I would add some clarification to this
paragraph. 

[rp] Correct, that is the assumption. We will definitely add some
clarification to it. 

6. page 6, Traffic generation: "It is recommended that the traffic is not
generated in round-robin fashion to each of the prefixes". 

This may be difficult to achieve with one TG interface. I would use 3 TG
interfaces in this case - one per stream for better accuracy. Or use traffic
rate high enough to neglect round-robbin effect. Either way, that should be
explained.

[rp] I agree, whatever the methodology is, we should explain it.

7. page 6: I would explain TA and TG abbreviations under the picture just
for the sake of completeness.

[rp]  Certainly.

[rp] Oops! Another overlook.

 9. page 7, Test Methodology: Are you covering both Single Nexthop FECs and
Multi Next Hop FECs cases with the same procedure? If so, Test Setup and
Test Configuration should not mention 2 parallel interfaces to a downstream
node, as used in Single Nexthop case. It may be easier to include separate
Test setup/Test Configuration for these two cases.

[rp] I like the suggestion, we should have two setups one highlighting the
Single nexthop FECs, and other referring to Multi Next hop  

scenarios.

Once again I really appreciate your feedback on the document, and hopefully,
once we have your contribution, we should able to include it in our next
version.

Thanks,

Andrey

  _____  

Dear BMWG-ers,

We as a LDP convergence benchmarking author team would like to seek input
from the group on the updated terminology document, and the new methodology
document that we submitted recently to the BMWG. We look forward to your
comments on both the drafts. 

1. draft-eriksson-ldp-convergence-term-04.txt
(http://www.ietf.org/internet-drafts/draft-eriksson-ldp-convergence-term-04.
txt)

2.	 LDP convergence methodology
(http://www.ietf.org/internet-drafts/draft-karthik-bmwg-ldp-convergence-meth
-00.txt) 

a.	Submitted version 00 with preliminary test cases, more to be added
as we progress 
b.	Draft to compliment the terminology document 
c.	Intent to produce a formal proposal after initial review  

     Thank you,