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

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Thu, 26 Apr 2007 21:39:13 -0400

Hi Samir,

I was able to review the draft and do believe that the standardization of RSVP benchmarking in the scope of TE as well as diff-serv are worthwhile areas of work.

1) In reference to the 'service provider' language. Can we change this to the much more general 'network operators' term? 

2) For refresh reduction is there a reference RFC/draft?

3) One thing I see missing esp in context of CPU/memory/stress is consideration for platforms that distribute the RSVP workload. Given the soft-state nature of RSVP there is a likelihood that portions of the state maintenance will be pushed off to distributed or auxiliary CPUs. We need to account for this and make sure that the test accurately conveys the system performance as well as the worst case 'single-path' performance.

4) In 4.1, (and other cases), I'm not sure of how the best way to do this but we need to make sure that the node-node signaling latency is correctly accounted (and subtracted) in the headend/midpoint/tail processing cases. If the headend is talking to a simulated network presented by test equipment, we need to make sure that the test equipment is not the bottleneck. Usually this not a problem with 1 or 2 sessions (we've done this lots of times with routing protocol scaling) but when mixing both session scale as well as latency it can get a bit tricky.

5) In 4.5 'Convergence of 25% of LSP on MPLS TE Mid-Point'. I like this idea. How about also adding a TC for length of time taken to signal additional LSPs when X # of LSPs are already up and being maintained?

Regards,

-- 
Aamer Akhter / [email-masked]
Ent & Commercial Systems, cisco Systems

"Samir Vapiwala (svapiwal)" <[email-masked]> wrote in message news:<[email-masked]>...
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

----------

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

---

From: "Karu Ratnam \(kratnam\)" <[email-masked]>
Date: Mon, 30 Apr 2007 14:26:35 -0400

Hi Aamer,
Thanks for your review.. Please see the in-line response. 

> -----Original Message-----
> From: Aamer Akhter (aakhter) 
> Sent: Thursday, April 26, 2007 9:39 PM
> To: [email-masked]
> Cc: Samir Vapiwala (svapiwal)
> Subject: [bmwg] Re: 
> draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt
> 
> Hi Samir,
> 
> I was able to review the draft and do believe that the 
> standardization of RSVP benchmarking in the scope of TE as 
> well as diff-serv are worthwhile areas of work.
> 
> 1) In reference to the 'service provider' language. Can we 
> change this to the much more general 'network operators' term? 

[Karu Ratnam] Yes, makes sense. 

> 2) For refresh reduction is there a reference RFC/draft?

[Karu Ratnam] RFC2961 refered in the reference section.

> 
> 3) One thing I see missing esp in context of 
> CPU/memory/stress is consideration for platforms that 
> distribute the RSVP workload. Given the soft-state nature of 
> RSVP there is a likelihood that portions of the state 
> maintenance will be pushed off to distributed or auxiliary 
> CPUs. We need to account for this and make sure that the test 
> accurately conveys the system performance as well as the 
> worst case 'single-path' performance.

[Karu Ratnam] You are absolutely correct that there is potential that it
could be distributed or offloaded, and we should consider that option.
However, we are not aware of any distributed/offloaded implementation of
RSVP and want to seek response from the bmwg community whether there is
a need to consider distributed/offloaded implementation at this point. 

> 
> 4) In 4.1, (and other cases), I'm not sure of how the best 
> way to do this but we need to make sure that the node-node 
> signaling latency is correctly accounted (and subtracted) in 
> the headend/midpoint/tail processing cases. If the headend is 
> talking to a simulated network presented by test equipment, 
> we need to make sure that the test equipment is not the 
> bottleneck. Usually this not a problem with 1 or 2 sessions 
> (we've done this lots of times with routing protocol scaling) 
> but when mixing both session scale as well as latency it can 
> get a bit tricky.

[Karu Ratnam] My understanding is test tools do not perform node to node
processing of the incoming messages. As such, the tool emulated nodes
should not be considered as part of num of hops for in the testing.
Emulation should be only for populating the database. True, one should
make sure that the tool should not be the bottleneck. Not sure we need
to recommend calibrating the tool for various RSVP-TE related
performance/latency of the tool. Comments welcome. 

> 
> 5) In 4.5 'Convergence of 25% of LSP on MPLS TE Mid-Point'. I 
> like this idea. How about also adding a TC for length of time 
> taken to signal additional LSPs when X # of LSPs are already 
> up and being maintained?

[Karu Ratnam] I agree.. We need to make this as a variable and can
recommend some possible values. We already recommend 25% of LSPs new.
How about say 5% new. Any other values?
Or, are you asking X num of LSPs are already signalled (recommend X =
1000, 2000, 5000, 10000) and signal another Y number of new LSPs (Y = 5,
10, 100)?

Again, thanks for reviewing it.
Karu-

> "Samir Vapiwala (svapiwal)" <[email-masked]> wrote in 
> message 
> news:<[email-masked]
> r.cisco.com>...
> Hi folks,
>

---

From: "Aamer Akhter \(aakhter\)" <[email-masked]>
Date: Mon, 30 Apr 2007 15:28:43 -0400

Hi Karu,

> 1000, 2000, 5000, 10000) and signal another Y number of new LSPs (Y =
> 5, 10, 100)?

I was talking about the latter case where we build more tunnels in addition to an existing base.

> From: Karu Ratnam (kratnam)
> Sent: Monday, April 30, 2007 2:27 PM
> To: Aamer Akhter (aakhter); [email-masked]
> Subject: RE: [bmwg] Re: draft-vapiwala-bmwg-rsvpte-convergence-
> motivation-00.txt
> 
> Hi Aamer,
> [Karu Ratnam] You are absolutely correct that there is potential that
> it could be distributed or offloaded, and we should consider that
> option. However, we are not aware of any distributed/offloaded
> implementation of RSVP and want to seek response from the bmwg
> community whether there is a need to consider distributed/offloaded
> implementation at this point.
> 
> >
> [Karu Ratnam] My understanding is test tools do not perform node to
> node processing of the incoming messages. As such, the tool emulated
> nodes should not be considered as part of num of hops for in the
> testing. Emulation should be only for populating the database. True,
> one should make sure that the tool should not be the bottleneck. Not
> sure we need to recommend calibrating the tool for various RSVP-TE
> related performance/latency of the tool. Comments welcome.
> 
> >
> 1000, 2000, 5000, 10000) and signal another Y number of new LSPs (Y =
> 5, 10, 100)?
>

---

From: "Karu Ratnam \(kratnam\)" <[email-masked]>
Date: Mon, 30 Apr 2007 16:33:50 -0400

Hi Aamer,
Sure.. We will add the test case.
Thanks.
Karu-

> Hi Karu,
> 
> > > 5) In 4.5 'Convergence of 25% of LSP on MPLS TE 
> Mid-Point'. I like 
> > > this idea. How about also adding a TC for length of time taken to 
> > > signal additional LSPs when X # of LSPs are already up and being 
> > > maintained?
> > 
> > > standardization of RSVP benchmarking in the scope of TE 
> as well as 
> > > diff-serv are worthwhile areas of work.
> > >
> > > 1) In reference to the 'service provider' language. Can we change 
> > > this to the much more general 'network operators' term?
> > 
> > > 3) One thing I see missing esp in context of CPU/memory/stress is 
> > > consideration for platforms that distribute the RSVP 
> workload. Given 
> > > the soft-state nature of RSVP there is a likelihood that 
> portions of 
> > > the state maintenance will be pushed off to distributed 
> or auxiliary 
> > > 4) In 4.1, (and other cases), I'm not sure of how the 
> best way to do 
> > > this but we need to make sure that the node-node 
> signaling latency 
> > > is correctly accounted (and subtracted) in the 
> headend/midpoint/tail 
> > > processing cases. If the headend is talking to a 
> simulated network 
> > > presented by test equipment, we need to make sure that the test 
> > > equipment is not the bottleneck. Usually this not a 
> problem with 1 
> > > or 2 sessions (we've done this lots of times with routing 
> protocol 
> > > scaling) but when mixing both session scale as well as latency it 
> > > can get a bit tricky.
> > 
> > > 5) In 4.5 'Convergence of 25% of LSP on MPLS TE 
> Mid-Point'. I like 
> > > this idea. How about also adding a TC for length of time taken to 
> > > signal additional LSPs when X # of LSPs are already up and being 
> > > maintained?
> > 
> > > "Samir Vapiwala (svapiwal)" <[email-masked]> wrote in message 
> > > 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