Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
RFC 4920

Approval announcement
Draft of message to be sent after approval:

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: 'Crankback Signaling Extensions for 
         MPLS and GMPLS RSVP-TE' to Proposed Standard 

The IESG has approved the following document:

- 'Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE '
   <draft-ietf-ccamp-crankback-07.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-crankback-07.txt

Technical Summary
 
   In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) and Generalized MPLS
   (GMPLS) Traffic Engineered (TE) Label Switched Path (LSP) setup
   requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP recovery to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in "RSVP-TE: Extensions to
   RSVP for LSP Tunnels", RFC3209, and GMPLS signaling as defined in
   "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
   Functional Description", RFC3473. These extensions mean that the LSP
   setup request can be retried on an alternate path that detours around
   blocked links or nodes.
 
Working Group Summary
 
   No dissent. There was some comment that the document contains too
   many sub-TLVs for conveying crankback information , but for each
   individual TLV the consensus was to retain it (see PROTO writeup
   in comments in ID tracker). 
 
Protocol Quality
 
   Ross Callon reviewed this for the IESG.
   The spec has been updated in response to comments from the AD (Ross)
   as well as Security Directorate comments. The document was also 
   liaisoned and reviewed by ITU-T's SG15.

Note to RFC Editor
 
   There are a few typos, particularly in documents referenced,
   that need to be corrected. The set of corrections (provided by
   Adrian Farrel):

   ====
   Section 2.1
   s/[RC3473]/[RFC3473]/
   ===
   Section 4.5, point 4)
   s/[RFC4373]/[RFC3473]/
   ===
   Section 13
   DELETE
     [G8080]   ITU-T Recommendation G.808/Y.1304, Architecture for the
               Automatically Switched Optical Network (ASON), November
               2001. For information on the availability of this
               document, please see http://www.itu.int.
   ===
   Section 13
   ADD
     [RFC4201] Kompella, K., Rekhter, Y., and Berger, L. "Link Bundling
               in MPLS Traffic Engineering (TE)", RFC 4201, October
               2005.
   ===