Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
draft-ietf-ccamp-rsvp-restart-ext-09

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    ccamp mailing list <ccamp@ops.ietf.org>, 
    ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Protocol Action: 'Extensions to GMPLS RSVP Graceful 
         Restart' to Proposed Standard 

The IESG has approved the following document:

- 'Extensions to GMPLS RSVP Graceful Restart '
   <draft-ietf-ccamp-rsvp-restart-ext-10.txt> as a Proposed Standard

This document is the product of the Common Control and Measurement Plane 
Working Group. 

The IESG contact persons are Ross Callon and David Ward.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rsvp-restart-ext-10.txt

Ballot Text

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. 

Working Group Summary
 
  no dissent reported (see PROTO writeup by Adrian Farrel)
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG. There are implementations 
   and it is reported that there is some deployment by "optical 
   vendors" (presumably optical switches).

RFC Editor Note