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

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?
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. Isn't it more likely
that the LSR would claim an admission control error?
3. "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.
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. 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.
6. Why does the new Error Codes have three Error Values, but the
Saturation TLV only have one bit defined?
7. Section 5.2. All "MUST" should be "SHOULD" I think.

My main question is why you need this draft. It seems that you can already
achieve all of these features using existing protocol elements. 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.

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