[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : I-D ACTION:draft-leroux-ccamp-ctrl-saturation-00.txt
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>