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

From: Arun Satyanarayana <[email-masked]>
Date: Tue, 11 Oct 2005 12:09:46 -0700

Hi Adrian, Kireeti,

Following are the mods to version -03, based on last call comments. Can 
we go through another short last call on this rev please?

-  Section 2 Terminology:
    Fix bad text
<   The reader is assumed to be familiar with the terminology defined in
<   xref target="RFC3209" /> and [RFC3473].
 >   The reader is assumed to be familiar with the terminology defined in
 >  [RFC3209] and [RFC3473].

- Section 4.2 Capability Object:
   Reverse ordering of definitions of T and R bits to match ordering in
   object

- Full I-D:
   Change "Restart_Caps" to "Restart_Cap" (to match definition in 3473).

- Section 4.4.1  Procedures for the Downstream Neighbor
   Clarify text: the downstream neighbor must send the T-bit in all
   Hellos
<   If the downstream RSVP neighbor of a restarting node is capable of
<   sending RecoveryPath messages to the restarting node, it MUST
include
<   the Capability object with the RecoveryPath Transmit Enabled (T) bit
<   set (1) in all its Hello messages sent to the restarting node.
 >   If a node is capable of sending RecoveryPath messages, it MUST
 >   include the Capability object with the RecoveryPath Transmit Enabled
 >   (T) bit set (1) in all its Hello messages.

- Section 4.4.2  Procedures for the Restarting Node
   Clarify text: the restarting node must send the R-bit in all Hellos
<   A restarting node that expects to recover RSVP state by the receipt
<   and processing of RecoveryPath messages according to procedures
<   defined in this document, MUST include the Capability object with the
<   RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to
<   its neighbors, during the Recovery Period.  The node MUST also
<   include the Restart_Caps object as defined in [RFC3473], in all those
<   Hello messages.
 >   A node that expects to recover RSVP state by the receipt and
 >   processing of RecoveryPath messages according to procedures defined
 >   in this document, MUST include the Capability object with the
 >   RecoveryPath Desired (R) bit set (1) in its RSVP Hello messages to
 >   its neighbors.  The node MUST also include the Restart_Cap object as
 >   defined in [RFC3473], in all those Hello messages.

- Section 4.5.2  Procedures for the Restarting Node
   Change response to received RecoveryPath messages outside the Recovery
   Period:
<   These procedures apply during the "state recovery process" and
<   "Recovery Period" as defined in Section 9.5.2 in [RFC3473].  Any
<   RecoveryPath message received after the Recovery Period has expired
<   MUST be discarded.  If no LSP state matching the RecoveryPath message
<   is located, the restarted node MAY send a PathTear message
<   constructed from the RecoveryPath message, to expedite the cleanup of
<   unrecovered RSVP and associated forwarding state downstream of the
<   restarted node.
 >   These procedures apply during the "state recovery process" and
 >   "Recovery Period" as defined in Section 9.5.2 in [RFC3473].  Any
 >   RecoveryPath message received after the Recovery Period has expired
 >   SHOULD be matched against local LSP state.  If matching fully
 >   resynchronized state is located, the node SHOULD send a Path message
 >   downstream.  If non-resynchronized or no LSP state matching the
 >   RecoveryPath message is located, the restarted node MAY send a
 >   PathTear message constructed from the RecoveryPath message, to
 >   expedite the cleanup of unrecovered RSVP and associated forwarding
 >   state downstream of the restarted node.

- Section 5.2.1  Procedures
   (Srefresh mechanism), clarify text: the restarting node must send
   the R-bit in all Hellos
<   To indicate to an RSVP neighbor that selective transmission of
<   RecoveryPath messages is desired, a restarting node MUST set (1) the
<   S-bit in the Capability object in all Hello messages it sends during
<   the Recovery Period to the neighbor.  When the restarting node does
 >   To indicate to an RSVP neighbor that selective transmission of
 >   RecoveryPath messages is desired, a node MUST set (1) the S-bit in
 >   the Capability object in all Hello messages it sends.  When the

- Section 7.  Acknowledgments
   Add Pavan Beeram.

- Section 8.  IANA Considerations
   Suggest values for the RecoveryPath msg and the Capability object
<   A new RSVP object using a Class-Number of form 10bbbbbb called the
<   Capability Object is defined in Section 4.2 in this document.  The
<   Class-Number is TBA by IANA.
 >   A new RSVP object using a Class-Number of form 10bbbbbb called the
 >   Capability Object is defined in Section 4.2 in this document.  The
 >   Class-Number is TBA by IANA.  A value of 132 is suggested.

<   A new RSVP message type called a RecoveryPath message is defined in
<   Section 4.1 of this document.  The RSVP message type is TBA by IANA.
 >   A new RSVP message type called a RecoveryPath message is defined in
 >   Section 4.1 of this document.  The RSVP message type is TBA by IANA.
 >   A value of 30 is suggested.

- Section 8.  IANA Considerations
   Fix typo in the bit names
<   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<   |                                                         |S|P|R|
<   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 >   |                                                         |T|R|S|
 >   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Arun (and co-authors)
==============================================================
-------- Original Message --------
Subject: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt
Date: Mon, 03 Oct 2005 15:50:02 -0400
From: [email-masked]
To: [email-masked]
CC: [email-masked]

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, et al.
	Filename	: draft-ietf-ccamp-rsvp-restart-ext-04.txt
	Pages		: 24
	Date		: 2005-10-3
	
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-04.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] 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-04.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-04.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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 11 Oct 2005 20:48:44 +0100

Thanks for the note Arun,

It looks to me that while most of these changes are editorial, the change
to 4.5.2 is substantive.

Therefore we will have a further short WG last call.

The last call will complete on Wednesday 19th October at 12 noon GMT.

Send your comments to the list please.

Thanks,
Adrian
----- Original Message ----- 
From: "Arun Satyanarayana" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "Kireeti Kompella"
<[email-masked]>
Cc: <[email-masked]>; "Lou Berger" <[email-masked]>; "Dimitri
Papadimitriou" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; "Anca Zamfir" <[email-masked]>; "Reshad Rahman"
<[email-masked]>; "Junaid Israr" <[email-masked]>; "Arun
Satyanarayana (asatyana)" <[email-masked]>
Sent: Tuesday, October 11, 2005 8:09 PM
Subject: Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 21 Oct 2005 18:27:12 +0100

Hi,

This last call completed without further comment. Arun needs to make one
minor format modification to appease the RFC editor and then we will pass
this on to the AD.

Thanks,
Adrian
----- Original Message ----- 
From: "Adrian Farrel" <[email-masked]>
To: <[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; "Dimitri Papadimitriou"
<[email-masked]>; "Anca Zamfir" <[email-masked]>; "Reshad Rahman"
<[email-masked]>; "Junaid Israr" <[email-masked]>; "Arun
Satyanarayana (asatyana)" <[email-masked]>; "Kireeti Kompella"
<[email-masked]>
Sent: Tuesday, October 11, 2005 8:48 PM
Subject: Further Working Group last call:
draft-ietf-ccamp-rsvp-restart-ext-04.txt