[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
Thanks for these comments
Please see inline
Regards
JL
>-----Message d'origine-----
>De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com]
>Envoyé : dimanche 6 mars 2005 22:31
>À : LE ROUX Jean-Louis RD-CORE-LAN
>Cc : zzx-adrian@olddog.co.uk; ccamp@ops.ietf.org
>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: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-sat
uration-0
> 0.txt>
>
>
>
>
> .
>