[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt
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" <asatyana@cisco.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>; "Kireeti Kompella"
<kireeti@juniper.net>
Cc: <ccamp@ops.ietf.org>; "Lou Berger" <lberger@movaz.com>; "Dimitri
Papadimitriou" <dimitri.papadimitriou@alcatel.be>; "Dimitri Papadimitriou"
<dpapadimitriou@psg.com>; "Anca Zamfir" <ancaz@cisco.com>; "Reshad Rahman"
<rrahman@cisco.com>; "Junaid Israr" <jisrar@cisco.com>; "Arun
Satyanarayana (asatyana)" <asatyana@cisco.com>
Sent: Tuesday, October 11, 2005 8:09 PM
Subject: 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.
>
>
>