Skip to main content

Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
RFC 5063

Revision differences

Document history

Date Rev. By Action
2018-12-20
09 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes extensions to the Resource Reservation Protocol (RSVP) Graceful Restart mechanisms defined in RFC …
Received changes through RFC Editor sync (changed abstract to 'This document describes extensions to the Resource Reservation Protocol (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. Those mechanisms do not fully support signaling state recovery on ingress nodes or recovery of all RSVP objects.

The extensions defined in this document build on the RSVP Hello extensions defined in RFC 3209, and extensions for state recovery on nodal faults defined in RFC 3473. Using these 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.

These extensions are not used to create or restore data plane state.

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 Label Switched Paths (LSPs). [STANDARDS-TRACK]')
2015-10-14
09 (System) Notify list changed from ccamp-chairs@ietf.org to (None)
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
09 (System) post-migration administrative database adjustment to the No Objection position for Magnus Westerlund
2007-10-17
09 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-10-17
09 Amy Vezza [Note]: 'RFC 5063' added by Amy Vezza
2007-10-16
09 (System) RFC published
2007-08-22
09 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2007-08-21
09 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2007-08-20
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-08-19
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-08-15
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-08-15
09 (System) IANA Action state changed to In Progress from Waiting on Authors
2007-08-15
09 (System) IANA Action state changed to Waiting on Authors from In Progress
2007-08-09
09 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-08-08
09 Amy Vezza IESG state changed to Approved-announcement sent
2007-08-08
09 Amy Vezza IESG has approved the document
2007-08-08
09 Amy Vezza Closed "Approve" ballot
2007-08-08
09 Ross Callon State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ross Callon
2007-08-08
09 (System) IANA Action state changed to In Progress
2007-07-30
09 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2007-07-03
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-07-03
09 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-09.txt
2007-02-28
09 Ross Callon State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Ross Callon
2007-01-30
09 Magnus Westerlund [Ballot Position Update] Position for Magnus Westerlund has been changed to No Objection from Discuss by Magnus Westerlund
2007-01-29
08 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-08.txt
2007-01-26
09 (System) Removed from agenda for telechat - 2007-01-25
2007-01-25
09 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-01-25
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2007-01-25
09 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson
2007-01-25
09 David Kessens [Ballot Position Update] New position, No Objection, has been recorded by David Kessens
2007-01-24
09 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to No Objection from Undefined by Mark Townsley
2007-01-24
09 Mark Townsley [Ballot Position Update] Position for Mark Townsley has been changed to Undefined from No Objection by Mark Townsley
2007-01-24
09 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2007-01-24
09 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded by Bill Fenner
2007-01-24
09 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-01-24
09 Magnus Westerlund
[Ballot discuss]
Section 4.1:

The section is neglecting to inform that the format of RecoveryPath message is the same as Reserver message but with message …
[Ballot discuss]
Section 4.1:

The section is neglecting to inform that the format of RecoveryPath message is the same as Reserver message but with message type set in the common header set to the TBD value. Please add a sentence indicating that the MSG Type field will have a different value. Quite obvious but there is no mention about this difference except in the IANA section.
2007-01-24
09 Magnus Westerlund [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund
2007-01-24
09 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2007-01-22
09 Sam Hartman
[Ballot discuss]
Based on a security review by Derek Atkins and comments from Sandy
Murphy, please help me understand why the trust model of this …
[Ballot discuss]
Based on a security review by Derek Atkins and comments from Sandy
Murphy, please help me understand why the trust model of this spec and
normal operation of RSVP is the same. In particular, what damage can
be done by a malicious peer sending back altered contents of path
messages?  How could the same damage be done in the normal protocol?


It may well be that writing text to cover these issues is too
expensive.  If the authors would like to discuss with me offline that
could work too.  Text is of course preferred if it is relatively easy
to write because then the entire world can review our findings.
2007-01-22
09 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2007-01-22
09 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-01-22
09 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2007-01-22
09 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2007-01-22
09 Brian Carpenter
[Ballot comment]
Minor open issue from gen-ART review by Elwyn Davies:

My remaining comment relates to the transient situation that could occur as a result …
[Ballot comment]
Minor open issue from gen-ART review by Elwyn Davies:

My remaining comment relates to the transient situation that could occur as a result of the (hopefully rare) eventuality noted in the last para of s4.4.2, where the node switches from using the new RecoveryPath mechanism back to using the old mechanism part way through recovery (possibly because of a failure downstream?)  My query related to whether the partial state from RecoveryPath messages should be used at all in this case.  I was unclear as to whether there could be a conflict between the partial state and information received after the switch.  The authors claim that the clear up at the end of the Recovery Period (s4.5.2.3) deals with the problem but I am not quite convinced.  I would like to see some justification as to why there is not a problem - I presume the occasion where the switch might occur is when a path switch was in progress resulting in a downstream node change, maybe?  This is an awkward corner case clearly but I think it deserves a sentence (or some real explanaion of why it does not result in a conflict).  A similar issue applies to s5.2.1.
2007-01-22
09 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded by Brian Carpenter
2007-01-18
09 Samuel Weiler Request for Early review by SECDIR Completed. Reviewer: Derek Atkins.
2007-01-17
09 Ross Callon State Changes to IESG Evaluation from AD Evaluation::AD Followup by Ross Callon
2007-01-17
09 Ross Callon Placed on agenda for telechat - 2007-01-25 by Ross Callon
2007-01-17
09 Ross Callon [Ballot Position Update] New position, Yes, has been recorded for Ross Callon
2007-01-17
09 Ross Callon Ballot has been issued by Ross Callon
2007-01-17
09 Ross Callon Created "Approve" ballot
2007-01-17
07 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-07.txt
2007-01-16
09 Ross Callon
Proto writeup by Adrian Farrel:

Here is the proto write up for draft-ietf-ccamp-rsvp-restart-ext.

Cheers,
Adrian

===

1. Have the chairs personally reviewed this version of …
Proto writeup by Adrian Farrel:

Here is the proto write up for draft-ietf-ccamp-rsvp-restart-ext.

Cheers,
Adrian

===

1. Have the chairs personally reviewed this version of the
  Internet Draft (ID), and in particular, do they believe
  this ID is ready to forward to the IESG for publication?

Yes.


2. Has the document had adequate review from both key WG
  members and key non-WG members? Do you have any concerns
  about the depth or breadth of the reviews that have been
  performed?

Pretty good review and implementation.


3. Do you have concerns that the document needs more review
  from a particular (broader) perspective (e.g., security,
  operational complexity, someone familiar with AAA, etc.)?

No concerns.
Note that we have just had review from SecDir that gives rise to the need
for a couple of new sentences (this resulted in -07).


4. Do you have any specific concerns/issues with this
  document that you believe the ADs and/or IESG should be
  aware of? For example, perhaps you are uncomfortable with
  certain parts of the document, or have concerns whether
  there really is a need for it. In any event, if your
  issues have been discussed in the WG and the WG has
  indicated it that it still wishes to advance the document,
  detail those concerns in the write-up.

Some WG members raised issues about how to handle multiple simultaneous
control plane failures. These failures can be handled by the existing
procedures, but are not documented in this I-D. The consensus of the WG was to leave this as it is, and open up a new I-D to show the applicability of these protocol extensions to a variety of failure cases. The alternative of documenting those cases in this I-D was deemed to over-complicate the I-D with second order (or higher) error cases.


5. How solid is the WG consensus behind this document? Does
  it represent the strong concurrence of a few individuals,
  with others being silent, or does the WG as a whole
  understand and agree with it?

Reasonable consensus.


6. Has anyone threatened an appeal or otherwise indicated
  extreme discontent? If so, please summarise the areas of
  conflict in separate email to the Responsible Area
  Director.

No.


7. Have the chairs verified that the document adheres to all
  of the ID Checklist items ?

Yes.


8. Is the document split into normative and informative
  references? Are there normative references to IDs, where
  the IDs are not also ready for advancement or are
  otherwise in an unclear state? (note here that the RFC
  editor will not publish an RFC with normative references
  to IDs, it will delay publication until all such IDs are
  also ready for publication as RFCs.)

All references shown are Normative. This is a correct decision.


9. What is the intended status of the document? (e.g.,
  Proposed Standard, Informational?)

Standards Track


10. For Standards Track and BCP documents, the IESG approval
  announcement includes a write-up section with the
  following sections:

a. Technical Summary

  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.  Those mechanisms do not fully support
  signaling state recovery on ingress nodes or recovery of all RSVP
  objects.

  The extensions defined in this document build on the RSVP Hello
  extensions defined in RFC 3209, and extensions for state recovery on
  nodal faults defined in RFC 3473.  Using these 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.

b. Working Group Summary

The WG consensus process was smooth.

c. Protocol Quality

The extensions are implemented and deployed by a number of optical vendors. This behavior is particularly required in transport networks where data traffic continues to flow even after control plane failures and the control plane must be resynchronized on recovery.

Packet vendors are increasingly interested in "non-stop forwarding" and are also considering MPLS-TE networks as transport networks. Thus, these
features are finding themselves on the roadmaps of packet vendors.
2006-12-08
09 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-12-08
06 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-06.txt
2006-11-08
09 (System) Request for Early review by SECDIR is assigned to Derek Atkins
2006-11-08
09 (System) Request for Early review by SECDIR is assigned to Derek Atkins
2006-10-04
09 Ross Callon State Changes to AD Evaluation::Revised ID Needed from Waiting for Writeup by Ross Callon
2006-09-15
09 Yoshiko Fong
IANA Last Call Comment:

First assignment:

Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at …
IANA Last Call Comment:

First assignment:

Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
table named "Class Names, Class Numbers, and Class Types"

TDB1/132 Capability Object [RFC-ccamp-rsvp-restart-ext]
c-type
1 Capability Object

Second Assignment:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
table named "Message Types"
TBD2/30 RecoveryPath [RFC-ccamp-rsvp-restart-ext]

Third Assignement:
Upon approval of this document, the IANA will make the following assignments
in the "RSVP PARAMETERS" registry located at
http://www.iana.org/assignments/rsvp-parameters
create a new table named "Capability Object values"
with allocation policy of IETF standards action.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |T|R|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

RecoveryPath Transmit Enabled (T): 1 bit [RFC-ccamp-rsvp-restart-ext]

RecoveryPath Desired (R): 1 bit [RFC-ccamp-rsvp-restart-ext]

RecoveryPath Srefresh Capable (S): 1 bit [RFC-ccamp-rsvp-restart-ext]

We understand the above to be the only IANA Actions for this document.
2006-09-08
09 (System) State has been changed to Waiting for Writeup from In Last Call by system
2006-08-25
09 Amy Vezza Last call sent
2006-08-25
09 Amy Vezza State Changes to In Last Call from Last Call Requested by Amy Vezza
2006-08-24
09 Ross Callon State Changes to Last Call Requested from AD Evaluation by Ross Callon
2006-08-24
09 Ross Callon Last Call was requested by Ross Callon
2006-08-24
09 (System) Ballot writeup text was added
2006-08-24
09 (System) Last call text was added
2006-08-24
09 (System) Ballot approval text was added
2006-07-24
09 Bill Fenner State Change Notice email list have been change to ccamp-chairs@tools.ietf.org from kireeti@juniper.net, adrian@olddog.co.uk
2006-07-07
09 Ross Callon State Changes to AD Evaluation from Publication Requested by Ross Callon
2006-04-20
09 Ross Callon Shepherding AD has been changed to Ross Callon from Alex Zinin
2005-10-31
09 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2005-10-25
05 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-05.txt
2005-10-03
04 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-04.txt
2005-07-19
03 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-03.txt
2005-03-21
02 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-02.txt
2005-02-21
01 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-01.txt
2004-10-11
00 (System) New version available: draft-ietf-ccamp-rsvp-restart-ext-00.txt