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

From: "Esa Salahuddin \(esalahud\)" <[email-masked]>
Date: Tue, 12 Jun 2007 15:07:43 -0400

Good work guys!
 
I think its a worthwhile idea to benchmark MPLS TE convergence, and this
draft is certainly a step in the right direction. It seems to be well
thought out document and I agree with what is being proposed in general.
 
However, i think this draft should focus on TE headend convergence and
not worry about the TE midpoint convergence. Since TE LSPs midpoints do
nothing more than RSVP signaling and label allocation; i doubt if this
benchmarking will yied any different results than whatever is out there
for any network node's capacity to handle network protocols' packets.
Also, if even those numbers are not already out there; this should be
done under some generic performance work iterm and not under the label
of MPLS TE convergence benchmarking.
 
Similiarly, benchmarking using RSVP authentication doesn't look like a
good benchmark to me. Need of RSVP authentication exists only on ASBRs
and its hard to perceive a need of thousands or even hundreds of
Inter-AS TE LSPs. Since, the number of LSPs is very small in this case;
any performance hit because of authentication is immaterial.
 
Last, what is the significance of benchmarking convergence of 25% of the
LSPs, and also doing it on a TE LSP midpoint? Why not 10% or 50%? And
why not to do it on TE LSP headpoint?
 
Rest is all good stuff, keep it up!
 
thx, esa

________________________________

	From: Samir Vapiwala (svapiwal) 
	Sent: Wednesday, April 18, 2007 11:47 AM
	To: [email-masked]
	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

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

---

From: "Rajiv Papneja" <[email-masked]>
Date: Fri, 15 Jun 2007 11:24:31 -0400

Hello Esa,

Thanks for your review of the document and feedback. Please see inline
response:

  _____  

From: Esa Salahuddin (esalahud) [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 3:08 PM
To: Samir Vapiwala (svapiwal); [email-masked]
Cc: Rajiv Papneja
Subject: RE: [bmwg] draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Good work guys!

However, i think this draft should focus on TE headend convergence and not
worry about the TE midpoint convergence. Since TE LSPs midpoints do nothing
more than RSVP signaling and label allocation; i doubt if this benchmarking
will yied any different results than whatever is out there for any network
node's capacity to handle network protocols' packets. Also, if even those
numbers are not already out there; this should be done under some generic
performance work iterm and not under the label of MPLS TE convergence
benchmarking.

[rp] You could be correct, but we feel that TE Mid-point convergence is very
important and infact more important than Head -end convergence. Difference
between head -end and mid-point convergence is the number of rsvp messages
being processed at any time. Considering there are 2000 TE LSPs signaled,
the maximum no. of RSVP messages on head-end would be 4000(2000 path and
2000 resv)  but at the mid-point this number is aggregated from other
head-end routers as well who are signaling through this node. For
discussion, if there are about 40K mid-point LSPs, then twice the number of
RSVP messages are being processed (40k path and 40k resv).  So about 80k
RSVP Messages has to be installed on mid-point router (remember these are
not transit messages since, each message creates a state on mid-point router
in addition to getting accepted to the rsvp bandwidth pool).   Furthermore,
each message has to go through the rate-limit queue before it is sent out to
the egress interface. Other parameters that need to be considered include
rate-limit parameter, how many rsvp messages should be queued on egress
interface and at what rate these messages are processed so that no message
is dropped due to egress interface queue overflow. This governs the
re-transmission of the messages which if not handled correctly may impact
the overall convergence at the mid-point node.

Similiarly, benchmarking using RSVP authentication doesn't look like a good
benchmark to me. Need of RSVP authentication exists only on ASBRs and its
hard to perceive a need of thousands or even hundreds of Inter-AS TE LSPs.
Since, the number of LSPs is very small in this case; any performance hit
because of authentication is immaterial.

[rp]  From deployment perspective you may be right but we are measuring the
authentication cost associated with RSVP TE protocol

Last, what is the significance of benchmarking convergence of 25% of the
LSPs, and also doing it on a TE LSP midpoint? Why not 10% or 50%? And why
not to do it on TE LSP headpoint?

[rp] There were a few questions already on why 25% of LSPs are considered
and we will clarify this in the next version of the submission. It can be
10% 20% or any percentage of lsp and is purely a decision of the tester. 

Thanks once again for your feedback to the document and review.

thx, esa

  _____  

From: Samir Vapiwala (svapiwal) 
Sent: Wednesday, April 18, 2007 11:47 AM
To: [email-masked]
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-convergence-
motivation-00.txt>
http://www.ietf.org/internet-drafts/draft-vapiwala-bmwg-rsvpte-convergence-m
otivation-00.txt.

Thanks
Authors

---

From: "Esa Salahuddin \(esalahud\)" <[email-masked]>
Date: Mon, 18 Jun 2007 14:15:10 -0400

Hi Rajiv,
 
I never really doubted the need for TE midpoint convergence numbers,
what i really was saying is this number is probably no different from a
node's capacity to handle any control plane messages and hence should be
targetted in a broad based work item instead of doing it in a MPLS TE
convergence draft. For RSVP authentication, i do think its not a useful
benchmark. I would love to see this effort focusing on whats really
useful and specific to MPLS TE convergence; however, i leave that to you
folks.
 
thx, esa

	From: Rajiv Papneja [mailto:[email-masked]] 
	Sent: Friday, June 15, 2007 11:25 AM
	To: Esa Salahuddin (esalahud)
	Cc: Samir Vapiwala (svapiwal); [email-masked]
	Subject: RE: [bmwg]
draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

	Hello Esa,

	Thanks for your review of the document and feedback. Please see
inline response:

	Subject: RE: [bmwg]

	Good work guys!

	I think its a worthwhile idea to benchmark MPLS TE convergence,
and this draft is certainly a step in the right direction. It seems to
be well thought out document and I agree with what is being proposed in
general.

	However, i think this draft should focus on TE headend
convergence and not worry about the TE midpoint convergence. Since TE
LSPs midpoints do nothing more than RSVP signaling and label allocation;
i doubt if this benchmarking will yied any different results than
whatever is out there for any network node's capacity to handle network
protocols' packets. Also, if even those numbers are not already out
there; this should be done under some generic performance work iterm and
not under the label of MPLS TE convergence benchmarking.

	[rp] You could be correct, but we feel that TE Mid-point
convergence is very important and infact more important than Head -end
convergence. Difference between head -end and mid-point convergence is
the number of rsvp messages being processed at any time. Considering
there are 2000 TE LSPs signaled, the maximum no. of RSVP messages on
head-end would be 4000(2000 path and 2000 resv)  but at the mid-point
this number is aggregated from other head-end routers as well who are
signaling through this node. For discussion, if there are about 40K
mid-point LSPs, then twice the number of RSVP messages are being
processed (40k path and 40k resv).  So about 80k RSVP Messages has to be
installed on mid-point router (remember these are not transit messages
since, each message creates a state on mid-point router in addition to
getting accepted to the rsvp bandwidth pool).   Furthermore, each
message has to go through the rate-limit queue before it is sent out to
the egress interface. Other parameters that need to be considered
include rate-limit parameter, how many rsvp messages should be queued on
egress interface and at what rate these messages are processed so that
no message is dropped due to egress interface queue overflow. This
governs the re-transmission of the messages which if not handled
correctly may impact the overall convergence at the mid-point node.

	Similiarly, benchmarking using RSVP authentication doesn't look
like a good benchmark to me. Need of RSVP authentication exists only on
ASBRs and its hard to perceive a need of thousands or even hundreds of
Inter-AS TE LSPs. Since, the number of LSPs is very small in this case;
any performance hit because of authentication is immaterial.

	[rp]  From deployment perspective you may be right but we are
measuring the authentication cost associated with RSVP TE protocol

	Last, what is the significance of benchmarking convergence of
25% of the LSPs, and also doing it on a TE LSP midpoint? Why not 10% or
50%? And why not to do it on TE LSP headpoint?

	[rp] There were a few questions already on why 25% of LSPs are
considered and we will clarify this in the next version of the
submission. It can be 10% 20% or any percentage of lsp and is purely a
decision of the tester. 

	thx, esa

		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> .

		Thanks
		Authors

---

From: "Rajiv Papneja" <[email-masked]>
Date: Thu, 21 Jun 2007 17:52:56 -0400

Hi Esa,

I agree with you to that we should include all aspects that are relevant to
the MPLS-TE convergence but could you please suggest any other similar
protocol with stateful characteristics that handles the control plane
messages similar to RSVP on every hop along the path?  If there is any other
draft within BMWG that benchmarks a similar protocol then we can leave it
out of the current scope, otherwise we would like to keep it in under the
current scope. 

Also we think it is worth including the measurement of convergence cost
associated with RSVP authentication.

Thanks a bunch for your feedback so far.  /Rajiv

  _____  

From: Esa Salahuddin (esalahud) [mailto:[email-masked]] 
Sent: Monday, June 18, 2007 2:15 PM
To: Rajiv Papneja
Cc: Samir Vapiwala (svapiwal); [email-masked]
Subject: RE: [bmwg] draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Hi Rajiv,

I never really doubted the need for TE midpoint convergence numbers, what i
really was saying is this number is probably no different from a node's
capacity to handle any control plane messages and hence should be targetted
in a broad based work item instead of doing it in a MPLS TE convergence
draft. For RSVP authentication, i do think its not a useful benchmark. I
would love to see this effort focusing on whats really useful and specific
to MPLS TE convergence; however, i leave that to you folks.

thx, esa

  _____  

Hello Esa,

  _____  

Good work guys!

 

thx, esa

  _____  

Hi folks,

Thanks
Authors

---

From: "Esa Salahuddin \(esalahud\)" <[email-masked]>
Date: Fri, 22 Jun 2007 16:25:19 -0400

Hi,
 
I think most of the network protocols are stateful...and the processing
that happens at a node for installing the rsvp state is all local and is
independent of the workload for doing the same at the next or previous
node in the path. Since work doesn't add up along the path, so one
doesn't need a hop by hop protocol to compare numbers with rsvp.
 
However, i think we are digressing from the original comment. I thought
midpoint TE convergence effort being proposed was about the ability of a
midpoint to consume the surge of path/resv's once a node/link comes up;
and i was saying that is probably going to be similar to its ability to
handle any control packets; and I asked if this draft needs to worry
about it... I do understand that what processing gets triggered by a
consumed packet will indeed be different for different protocols and
will also depend upon the role of the router... like whether it is a
CSPF trigger or just a label allocation request.
 
thx,esa

	Sent: Thursday, June 21, 2007 5:53 PM

	Hi Esa,

	I agree with you to that we should include all aspects that are
relevant to the MPLS-TE convergence but could you please suggest any
other similar protocol with stateful characteristics that handles the
control plane messages similar to RSVP on every hop along the path?  If
there is any other draft within BMWG that benchmarks a similar protocol
then we can leave it out of the current scope, otherwise we would like
to keep it in under the current scope. 

	Also we think it is worth including the measurement of
convergence cost associated with RSVP authentication.

	

	Hi Rajiv,

	I never really doubted the need for TE midpoint convergence
numbers, what i really was saying is this number is probably no
different from a node's capacity to handle any control plane messages
and hence should be targetted in a broad based work item instead of
doing it in a MPLS TE convergence draft. For RSVP authentication, i do
think its not a useful benchmark. I would love to see this effort
focusing on whats really useful and specific to MPLS TE convergence;
however, i leave that to you folks.

	thx, esa

		

		Hello Esa,

		Thanks for your review of the document and feedback.
Please see inline response:

		From: Esa Salahuddin (esalahud)
[mailto:[email-masked]] 
		Sent: Tuesday, June 12, 2007 3:08 PM
		To: Samir Vapiwala (svapiwal); [email-masked]
		Cc: Rajiv Papneja
		Subject: RE: [bmwg]
draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

		Good work guys!

		I think its a worthwhile idea to benchmark MPLS TE
convergence, and this draft is certainly a step in the right direction.
It seems to be well thought out document and I agree with what is being
proposed in general.

		 

		Similiarly, benchmarking using RSVP authentication
doesn't look like a good benchmark to me. Need of RSVP authentication
exists only on ASBRs and its hard to perceive a need of thousands or
even hundreds of Inter-AS TE LSPs. Since, the number of LSPs is very
small in this case; any performance hit because of authentication is
immaterial.

		[rp]  From deployment perspective you may be right but
we are measuring the authentication cost associated with RSVP TE
protocol

		Last, what is the significance of benchmarking
convergence of 25% of the LSPs, and also doing it on a TE LSP midpoint?
Why not 10% or 50%? And why not to do it on TE LSP headpoint?

		[rp] There were a few questions already on why 25% of
LSPs are considered and we will clarify this in the next version of the
submission. It can be 10% 20% or any percentage of lsp and is purely a
decision of the tester. 

		Thanks once again for your feedback to the document and
review.

		thx, esa

			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

---

From: Al Morton <[email-masked]>
Date: Fri, 22 Jun 2007 16:39:52 -0400

At 04:25 PM 6/22/2007, Esa Salahuddin \(esalahud\) wrote:

Content-class:
urn:content-classes:message

Content-Type: multipart/alternative;

boundary="----_=_NextPart_001_01C7B50B.10E48D22"

Hi,

...

Folks,

The appended messages on this thread are exceeding the message size

limit on this list, and so are being held for the moderator

(me) to catch and release.  I also observe that the character

content is not that large, so...

I suggest:

* use plain text without much formatting (I think that several

people on the list have indicated that they prefer this format).

* If you're just replying, not typing answers in-line, then

lets depend on the archive to provide access to earlier messages

(should someone want to view them, even someone who deletes his

bmwg e-mail...).

thanks, and please don't take this as a criticism,

just a way to keep our list running efficiently!

Al

bmwg chair

---

From: "Esa Salahuddin \(esalahud\)" <[email-masked]>
Date: Fri, 22 Jun 2007 17:29:41 -0400

Al,
 
Sorry for keeping you busy on a friday afternoon ;)
 
It must be my Outlook that is generating all the formatting stuff. Too
bad that i can't blame it for keeping the original text of emails also! 
 
thx, esa

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 24 Jun 2007 12:14:31 -0400

In message <[email-masked]>
> CSPF trigger or just a label allocation request.

The real world situation of greatest interest is the failure of a link
and the subsequent rerouting of a large number of LSPs.  Take for
example a three link east-west cutset in the middle of the continental
US.  If half the LSR are on one side and half on the other and the
LSPs evenly distributed over the cutset, then for N nodes, about
2*(N/2)*(N/2)/3 or N*N/12 LSP have to be rerouted.  So if N=200, about
6,000 LSP are rerouted.

The real world example is provided since it is real world situations
that make benchmarking a relevant activity and not just a pointless
exercise.

The most computational work occurs at the ingress.  In the above
example each of 100 ingress reroutes about 60-70 LSPs.  The CSPF
computations doesn't amount to all that much but the CSPF and initial
signaling (PATH message) can be over a second on many routers.

At each midpoint, first reservable bandwidth is checked and the PATH
message either passes or fails the admission check.  If it passes, the
PATH message moves on.  If it doesn't signaling flows back to the
ingress.  When the RESV comes back, each LSR gets the label it needs
to install forwarding state.  It then signals back to the prior LSR.
This has been measured in the past at 50-100 msec per midpoint.
Multiply that by 10 hops and you've got 1/2 to 1 second before the
ingress gets a RESV.  The reason for that delay has much more to do
with the time it takes to install forwarding state than the time it
takes for signaling.

The second problem is that in a three link cutset, when one link is
lost if bandwidth on the remaining two links is sufficient but
limited, many LSP will be signaled that take the path which is the
shortest after the link failure is noticed.  The feedback in the form
of a reduction of reservable bandwidth is delayed (if nothing else by
speed of light delay with the ingress and bottleneck being 10-20 msec
away).  Many ingress will signal LSP that will be rejected.  The
reduction of reservable bandwidth should arrive somewhat concurrently
with the rejection and the ingress must resignal.  This adds signaling
and computational load to the ingress.

In the meantime some of the midpoints in real networks of this size
may be seeing on the order of thousands of LSP signaled due to the one
fault (some signaled, rejected downstream, and resignaled with a
slightly different ERO).  It is this fairly large volume of change and
the need to send forwarding changes in reasonable batches to the
forwarding cards and then get confirmation back from the forwarding
cards before passing back the RESV that makes the midpoint's workload
significant.

In the real world if the whole convergence happens in under 10 seconds
that is pretty good.  If it happens in a few seconds that is very
good.  AFAIK it doesn't happen in under a second.  For the networks
that have constrained their core to be under 100 routers, convergence
will be faster than for those that have hundreds of routers in the
core MPLS mesh.

Benchmarking both the ingress and midpoint is relevant.  Neither
ingress or midpoint has a trivial amount of work to do in a real world
convergence situation.  The implementations of major router vendors
could stand some improvement so this benchmarking could be very
useful.

Curtis

---

From: "Samir Vapiwala \(svapiwal\)" <[email-masked]>
Date: Mon, 25 Jun 2007 10:22:58 -0400

Hi Esa
 
ASFAIK, none of the state full protocol installs 80K states on the
routers  considering the example Rajiv gave. Furthermore,  RSVP protocol
also offers additional functionalities such as Refresh Reduction
(Reliable messages, Summary message and Bundle messages) and RSVP
rate-limit functionality that manages a high numbers of state full
session signaling and maintenance which none of the state full protocols
has it..
 
It would be great to learn a similar protocol that offers this
functionality and we would very happy to provide reference to draft
which you believes addresses mid-point convergence. I think it is to the
best interests that all protocols are handled separately when control
plane scalability is concerned.
 
Thanks
Samir

From: Esa Salahuddin (esalahud) 
Sent: Friday, June 22, 2007 4:25 PM
To: Rajiv Papneja
Cc: Samir Vapiwala (svapiwal); [email-masked]
Subject: RE: [bmwg]
draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

Hi,

 
thx,esa

---

From: "Esa Salahuddin \(esalahud\)" <[email-masked]>
Date: Tue, 26 Jun 2007 08:15:14 -0400

Samir,
 
I think Curtis has already spoken very comprehensively on the topic
about the real world numbers, actual issues involved and the behavior of
both headend and midpoint routers for convergence purposes and we should
defer to him.
 
thx, esa

	From: Samir Vapiwala (svapiwal) 
	Sent: Monday, June 25, 2007 10:23 AM
	To: Esa Salahuddin (esalahud); [email-masked]'
	Cc: 'Rajiv Papneja'; Karu Ratnam (kratnam)
	Subject: RE: [bmwg]
draft-vapiwala-bmwg-rsvpte-convergence-motivation-00.txt

	Hi Esa
	 
	ASFAIK, none of the state full protocol installs 80K states on
the routers  considering the example Rajiv gave. Furthermore,  RSVP
protocol also offers additional functionalities such as Refresh
Reduction (Reliable messages, Summary message and Bundle messages) and
RSVP rate-limit functionality that manages a high numbers of state full
session signaling and maintenance which none of the state full protocols
has it..

	Thanks
	Samir