[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further Working Group last call: draft-ietf-ccamp-rsvp-restart-ext-04.txt
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" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: "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>; "Kireeti Kompella"
<kireeti@juniper.net>
Sent: Tuesday, October 11, 2005 8:48 PM
Subject: 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.
> >
> >
> >
>
>
>
>