Re: I-D ACTION:draft-ietf-ccamp-crankback-06.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

After a long hiatus I have got around to the IETF last call comments for 
this draft.

The changes are:

- New final paragraph in Section 4.1 to address comments raised
 by Ross.
- Rewrite of Section 9 (IANA) for clarity, but no change in content.
- Rewrite of Section 10 to handle comments from the SecDir review.

The changes to Section 10 are substantive, but I don't think they will cause 
anyone any issues.

Thanks,
Adrian

----- Original Message ----- 
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Thursday, January 18, 2007 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-crankback-06.txt


> 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 : Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE
> Author(s) : A. Farrel, et al.
> Filename : draft-ietf-ccamp-crankback-06.txt
> Pages : 35
> Date : 2007-1-18
>
> 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. This offers significant improvements in the
>   successful setup and recovery ratios for LSPs, especially in
>   situations where a large number of setup requests are triggered at
>   the same time.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-06.txt