Subject: RE: [bmwg] draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

From: "Rajiv Papneja" <[email-masked]>
Date: Tue, 1 May 2007 14:39:30 -0400

Hi Ravesh,

Thanks for spending time to review the document, providing valuable feedback
and helping us in clarifying the text further. Please see my comments
inline. /R

From: Raveesh Janardan (rjanarda) [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 10:44 AM
To: [email-masked]; Rajiv Papneja; Karu Ratnam (kratnam); Samir Vapiwala
(svapiwal)
Subject: RE: [bmwg] draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Hi Folks
  
The effort on standardizing the convergence time benchmarking for TE tunnels
is
Certainly needed and will be useful.
 
 I have a few questions and comments on few items in the motivational draft
authored
by you. Please let me know if you need any clarifications on the following
comments/queries.
 
Regards
Raveesh Janardan
Cisco System

1. Section 3.5. Typo. Steady instead of stead
[rp] Absolutely!

2. May be good to mention  pre-existing TE/RSVP sessions impact the
performance?
[rp] I believe section 4.5 does address this part. Could you please clarify
this further?

3. In Section 3, TE PCALC/Routing module interaction could be a factor in
    Convergence time especially in interface flap case.
[rp] It is considered. We are calculating the total signaling time from the
instance when interface becomes operational until when last RSVP-TE LSP is
operationa. This includes the time required for IGP and Path calculation to
take place for every LSP setup. 

4. When you mention Refresh reduction parameters it may be good idea to
mention
     Rapid Retransmit and Acknowledgement time parameters which could be
fine tuned for
     Better convergence similar to Rate-limiting.
[rp] Sure, we should define Rapid Retransmit and Acknowledgement time in
scalability testing. Timer recommendation settings can be defined in the
meth draft.

5. In section 4 for the refresh reduction cases having a case to 
    Explicitly include Refresh Reduction with Bundling?  
[rp] Yes, we should consider message bundling since this feature is not
supported by every vendor and it is enabled if refresh reduction is enabled.
We can certainly add separate test with and without message bundling.

6.  Should GR/Fast hello's be considered as a factor in convergence time?
     This could be coupled with HA in case HA will be covered as part of
this draft.
[rp] I believe HA is out of scope of this effort and may be a candidate for
another document. What do you think?

7. It is good to see a test case scenario for RSVP Authentication. When the
scenario is 
     Expanded it would be good to include cases for different authentication
types like   
     MD5/SHA-1 and also inclusion test cases with and without Challenges.
[rp We will consider adding authentication modes in the methodology draft
and we believe it is a very good benchmarking aspect. 
 
_______________________________________________
bmwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bmwg