[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-03.txt
Version -03 is the updated version resulting from last-call comments.
A scalability concern was raised, where, the restarting node does not
support the mechanism in this I-D, but, one or more RSVP neighbors do.
This would result in unnecessary generation (and possible
retransmission) of RecoveryPath msgs by the neighbors, and, receive
processing of the RecoveryPath msg until the restarting node has to
decide to drop it. This may be a scalability issue when a large number
of LSPs are active on the restarting node.
The solution is to indicate the capability to transmit and receive
RecoveryPath msgs with 2 new bits in the Capability object.
Note: The above solution also addresses a similar concern raised
earlier, where, the restarting node support the extensions but one or
more of its neighbors do not. The restarting node would have to wait
until the end of the Recovery Period to revert to restart processing per
RFC3473. With an explicit advertisement of RecoveryPath capability, this
requirement no longer exists.
We (the co-authors) hope that a short last-call to review the above
change only is sufficient to progress the I-D. Please review and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
Title : Extensions to GMPLS RSVP Graceful Restart
Author(s) : A. Satyanarayana
Filename : draft-ietf-ccamp-rsvp-restart-ext-03.txt
Pages : 24
Date : 2005-7-19
This document describes extensions to the RSVP Graceful Restart
mechanisms defined in RFC 3473. The extensions enable the recovery
of RSVP signaling state based on the Path message last sent by the
node being restarted. Previously defined Graceful Restart
mechanisms, also called recovery from nodal faults, permit recovery
of signaling state from adjacent nodes when the data plane has
retained the associated forwarding state across a restart. These
mechanisms do not fully support signaling state recovery on ingress
nodes or recovery of all RSVP objects. The presented extensions use
the RSVP Hello extensions defined in RFC 3209, and extensions for
state recovery on nodal faults defined in RFC 3473. With the
presented extensions the restarting node can recover all previously
transmitted Path state including the Explicit Route Object and the
downstream (outgoing) interface identifiers. The extensions can also
be used to recover signaling state after the restart of an ingress
node. The extensions optionally support the use of Summary Refresh,
defined in RFC 2961, to reduce the number of messages exchanged
during the Recovery Phase when the restarting node has recovered
signaling state locally for one or more LSPs.
A URL for this Internet-Draft is:
To remove yourself from the I-D Announcement list, send a message to
email@example.com 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
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
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