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

Hi Andery

Thanks for reviewing and supporting this work item, we appreciate it.
pls see comments inline

________________________________

From: Andrey Kiselev (ankisele) 
Sent: Friday, April 20, 2007 6:07 PM
To: Samir Vapiwala (svapiwal); bmwg@ietf.org
Cc: Rajiv Papneja; Karu Ratnam (kratnam)
Subject: RE: [bmwg]
draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Hi Authors,

I reviewed the document, and I believe there is a need in standard for
benchmarking MPLS TE convergence. I was even surprised these items have
not been standardized yet. I have a few comments and questions on the
document.

1. You use terms MPLS TE convergence and RSVP TE convergence
interchangingly through the document. However, most items in section 3
are also applicable to classic RSVP. Are there any existing documents on
classic RSVP convergence? I think we should draw a line somewhere
between  MPLS TE convergence and RSVP convergence. There may be a space
for a separate document, covering classic RSVP benchmarking. 

SV- we will correct the terms use in above draft we'll use RSVP-TE.  You
are right it will be separate classic RSVP and RSVP-TE draft,  There is
already terminology draft for classic RSVP as
"draft-ietf-bmwg-benchres-term-08.txt" and authors are already working
on Methodology draft which will get published  soon. In addition you
would see separate term and meth documents for RSVP-TE

2. page 4 paragraph 3.3: RSVP rate-limit parameter definitely will
impact MPLS TE convergence, but how it applies to benchmarking? It is
user-configurable, and can be set to any value. 

SV- we will list out suggested rate-limit  values  for scalability in
methodology draft. if vendor does not support configurable rate-limit
option then one can use  default.

3. All factors listed in section 3 come either from RSVP, or system
limitations. Should it be something else in this list, like explicit vs.
dynamic paths or certain RSVP timers? 

SV - Explicit or dynamic should not impact convergence because both
needs to run CSPF...  I'm not aware of any other rsvp timer that could
can impact convergence of RSVP-TE,  We would like to ask this question
to the BMWG list if are missing anything here.

4. Section 4 MPLS TE Scalability and Convergence Performance cases:
What cases in section 4 are actually related to scalability? I would add
some case which would allow us to get this scalability number MAX x for
number of lsps. Should we also consider somehow number of nodes on the
path between headend and tailend? 

SV - All the cases in section 4 will impact scalability and convergence.
Section 5 suggests x number of lsp to be tested with every scenario
defined in section 4. In reference to the no. of number of hops, section
4.8 measures the latency of signal lsp in scale network. results from
that can be extrapolated for network of any size.  We'll be happy to
hear better ideas from BMWG list if any.

5. page 5 paragraph 4.6, 4.7: I would rephrase headers as "Convergence
with RSVP Authentication..." Otherwise it may be IGP authentication, LDP
authentication, etc. 

SV-  Convergence with RSVP Authentication sounds better and it
eliminates confusion, we'll change that. 

6. page 6 paragraph 5.1: Just curious - why wouldn't we start from 1
LSP? 

SV - Testcase 4.8 covers 1 lsp convergence in scaled network, The
granularity of measurements for large numbers of lsp will be coarser and
like not a usable for 1 or few numbers of lsp.

Thanks
Authors

Thank you,

Andrey

________________________________

From: Samir Vapiwala (svapiwal) 
Sent: Wednesday, April 18, 2007 11:47 AM
To: bmwg@ietf.org
Cc: Rajiv Papneja; Samir Vapiwala (svapiwal)
Subject: [bmwg] draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Hi folks,

We would like to seek your opinion on motivation draft that we have
recently published addressing the MPLS TE Convergence benchmarking. This
document describes the motivation for benchmarking MPLS traffic
engineering (TE) convergence using RSVP-TE as an underlying signaling
protocol. This document further provides an overview of the proposed
work item and we plan to produce a separate methodology and terminology
document if there is enough interest in the area. 

Kindly review the motivation document that has been recently posted in
the internet-draft directory-
http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-rsvpte-convergen
ce-motivation-00.txt
<http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-rsvpte-converge
nce-motivation-00.txt> .

We look forward to hearing your feedback and comments. 

Thanks
Authors