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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 8 Mar 2005 01:59:29 +0100

Hi dimitri

Thanks for these comments

Please see inline

Regards

JL

>-----Message d'origine-----
>De : dimitri papadimitriou [mailto:[email-masked]] 
>Envoyé : dimanche 6 mars 2005 22:31
>À : LE ROUX Jean-Louis RD-CORE-LAN
>Cc : [email-masked]; [email-masked]
>Objet : Re: RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
>
>
>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 - 

Yes, in a way, this can be seen as an additional constraint.
A head-end should avoid a saturated LSR when computing a path of a new LSP.

>note that in the former case flooding provides 
>you a notification mechanism after occurrence but does not deliver any 
>avoidance mechanism -

Yes it does. 
An LSR could anticipate the saturation, by setting the Saturation bit once a threshold is reached.
This is a local decision.

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

No this is not a router capability, this is a control plane status.

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

This a light and simple solution that IMHO solves the problem...

Thanks

JL

>
>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-sat
uration-0
>  0.txt>
> .