Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-06.txt

[Arun Satyanarayana <asatyana@cisco.com>]

Hi,

This re-spin includes text per Gen-Art review comments. The diffs
are:

Section 4.5.1: Fix Typo in heading:
Old: Procedures For The Downstream Neighbor
New: Procedures for the Downstream Neighbor


Section 4.5.1: Add clarification text per Gen-Art review comments:
Old:
   All RecoveryPath messages SHOULD be sent at least once within
   approximately 1/2 of the Recovery Time advertised by the restarted
   neighbor.  If there are many LSPs to be recovered by the restarted
   node, the downstream RSVP neighbor should avoid sending RecoveryPath
   messages in a short time interval, to avoid overloading the restarted
   node's CPU.  Instead it should spread the messages across 1/2 the
   Recovery Time interval.
New:
   All RecoveryPath messages SHOULD be sent at least once within
   approximately 1/2 of the Recovery Time advertised by the restarted
   neighbor.  If there are many LSPs to be recovered by the restarted
   node, the downstream RSVP neighbor should avoid sending RecoveryPath
   messages in a short time interval, to avoid overloading the restarted
   node's CPU.  Instead it should spread the messages across 1/2 the
   Recovery Time interval.  The range of Recovery Time is dependent on
   many factors including but not limited to the CPU processing power on
   the restarting node as well as the upstream and downstream neighbors,
   amount of CPU available for processing RSVP recovery procedures,
   implementation specifics that affect the amount of time taken to
   verify the received recovery state against existing forwarding plane
   state.  Such discussion is out of scope of this document.

Section 6: Add text per Gen-Art review comments:
   [RFC2747] provides mechanisms to protect against external agents from
   compromising the RSVP signaling state in an RSVP agent.  These
   mechanisms, when used with the new message and procedures introduced
   in this document, provide the same degree of protection to the
   restarting RSVP agent, against installing compromised signaling state
   from an external agent during its RSVP signaling state recovery.

Authors' Addresses: Update contact info

Regards,
Arun
==============================================================
Internet-Drafts@ietf.org wrote:

> 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, R. Rahman
> 	Filename	: draft-ietf-ccamp-rsvp-restart-ext-06.txt
> 	Pages		: 24
> 	Date		: 2006-12-8
> 	
> 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:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-06.txt
>
> To remove yourself from the I-D Announcement list, send a message to 
> i-d-announce-request@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-ietf-ccamp-rsvp-restart-ext-06.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@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-06.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.