[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-rsvp-restart-ext-04.txt
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: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
CC: ccamp@ops.ietf.org
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
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-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:
mailserv@ietf.org.
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.