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

From: dimitri papadimitriou <[email-masked]>
Date: Sun, 06 Mar 2005 22:31:03 +0100

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 -

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

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

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:[email-masked]] Envoyé : mardi 1 février 2005 19:41 À
>> : LE ROUX Jean-Louis RD-CORE-LAN Cc : [email-masked] 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"
>>  <[email-masked]> To: <[email-masked]> 
>> 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>
> 
> 
> 
> 
> .
>

---

From: JP Vasseur <[email-masked]>
Date: Sun, 6 Mar 2005 17:58:07 -0500

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

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

>>> 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
>>>  <[email-masked]> To: <[email-masked]> Sent:  
>>> Tuesday, February 01, 2005 7:21 AM Subject: TR: I-D