[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt

Hi Dimitri,

On Mar 6, 2005, at 4:31 PM, dimitri papadimitriou wrote:

hi jean-louis

the below discussion raises the issue that the decoupling of the control from the (data plane) resource admission control (driven by the Min/Max LSP bandwidith) raises the issue of the control plane saturation due to LSPs that do not reserve any bandwith/or allow for bandwidth reuse such low priority LSPs and therefore the #LSPs actually processed by the control plane can become much higher than the number of LSPs that could result from the Min LSP bandwidth parameter - this is a nice side effect of part of bunch of other control plane processing issues such prioritized treatment of control messages, concurrent requests, etc.

i think the problem statement is rather scoped, however the solution scope seems to me to be raising correlation issue and further relationship with the data plane resource re-optimization issues we were discussing on this list a couple of times - i could sum'up this in one sentence is it suitable to flood the state of the signaling control engine using flooding or is the intention to consider this as an additional constraint - note that in the former case flooding provides you a notification mechanism after occurrence but does not deliver any avoidance mechanism -


it provides a notification mechanism that a head-end should consider as a constraint.

this said is that really a "router capability" or do you mean here the capability to provide "control plane saturation tracking" ?


the later.

therefore, it would be probably advisable to be a bit less expeditive in terms of solution


"expeditive" ?

Thanks.

JP.

thanks,
- dimitri.

LE ROUX Jean-Louis RD-CORE-LAN wrote:

Hi Adrian,
Thanks a lot for these comments
Please see inline
Regards
JL

-----Message d'origine----- De : Adrian Farrel
[mailto:adrian@olddog.co.uk] Envoyé : mardi 1 février 2005 19:41 À
: LE ROUX Jean-Louis RD-CORE-LAN Cc : ccamp@ops.ietf.org Objet :
Re: I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Jean-Louis,
Thanks for this draft.
A couple of immediate thoughts.
1. What is wrong with using Error Code 23?

Error code 23 is used for "System Errors". IMHO the saturation
semantic defined here is quite different.

2. Will implementations really want to confess to the reason that
they are unable to handle more LSPs? It seems to me that it would
be a remarkably honest implementation that implemented this draft.

Bascially the draft proposes to handle properly control plane
saturation cases. If you want to handle these cases you need a
dedicated error code, this would allow Head-end LSRs to take
appropriate actions.

Isn't it more likely that the LSR would claim an admission control
error? 3.
Saturation is not and admission control problem
"The head-end should not reroute already established LSPs passing
through the saturated node." Why ever not? Surely this is local policy, and the ingress may know that the only way to route its new
and projected LSPs is to move some of the existing ones. 
Stability is better, the LSR is already supporting a set of TE-LSPs,
it is saturated, why would you want to move these LSPs?
4. Why is saturation a good thing to advertise in the

IGP? If an LSR wishes to prevent new LSPs being routed through it,
it should withdraw bandwidth just as it would if the signaling
elements of the control plane had failed. 5.

But what about 0 bandwidth LSPs? A head-end may select a node with 0
bandwidth available, when computing the path of a 0 bandwidth LSP. So
withdrawing bandwidth is not sufficient to handle properly control
plane saturations
Much of the draft restates default behavior (e.g. what to do when
you receive a Path message). This is interesting information for the reader, but I am not sure that it is right to present it here. 
Agree
6. Why does the new Error Codes have three Error Values,
but the Saturation TLV only have one bit defined?
Good point, we need to define 3 flags
7. Section 5.2. All "MUST" should be "SHOULD" I think. 
Why? This is IMHO a mandatory behavior for an implementation
compliant with this draft.

My main question is why you need this draft. It seems that you can
already achieve all of these features using existing protocol
elements.

I think that this would be cleaner with these light signaling and
routing extensions.

At most you might want to write a one page BCP to say what a
transit or egress LSP should do when it cannot handle a new LSP
because of some internal resource shortage other than an admission
control problem.

But the problem is that we consider that when a transit or egress LSR
cannot handle a new LSP because of some internal resource shortage
other than an admission control problem, it should notify the head
end about its saturation, and if you want proper reaction you need a
specific notification...thus dedicated error code points are required
Again thanks a lot for these comments
Regards
JL
Cheers, Adrian
----- Original Message ----- From: "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@francetelecom.com> To: <ccamp@ops.ietf.org> Sent: Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D
ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
Hi all,
We just posted a new draft related to (G)MPLS-TE control plane resource shortages. Your comments/feedbacks on this draft are
welcome.
Regards,
JL
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Procedure to handle (G)MPLS-TE control plane saturation Author(s) : J. Le Roux, et al. Filename :
draft-leroux-ccamp-ctrl-saturation-00.txt Pages : 10 Date :
2005-1-31
This document defines extensions to RSVP-TE (Resource Reservation Protocol-Traffic Engineering) and IGP (IS-IS and OSPF), in order to
signal control plane resources saturation, when an LSR runs out of
control plane resources available to support a new LSP. Such notification may serve as trigger for the impacted Head-end LSR to take appropriate actions.
A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl-sat
uration-0 0.txt
To remove yourself from the I-D Announcement list, send a message to
i-d-announce-request at ietf.org with the word unsubscribe in the
body of the message. You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
subscription settings.
Internet-Drafts are also available by anonymous FTP. Login with the
username "anonymous" and a password of your e-mail address. After
logging in, type "cd internet-drafts" and then "get
draft-leroux-ccamp-ctrl-saturation-00.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html or
ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to: mailserv at ietf.org. In the body type: "FILE
/internet-drafts/draft-leroux-ccamp-ctrl-saturation-00.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this feature,
insert the command "ENCODING mime" before the "FILE" command. To
decode the response(s), you will need "munpack" or a MIME-compliant
mail reader. Different MIME-compliant mail readers exhibit different
behavior, especially when dealing with "multipart" MIME messages
(i.e. documents which have been split up into multiple messages), so
check your local documentation on how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl- saturation-0
0.txt>
<ftp://ftp.ietf.org/internet-drafts/draft-leroux-ccamp-ctrl- saturation-0
0.txt>
.