RFC 4872, "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery", May 2007

Note: This RFC has been updated by RFC 4873, RFC 6780, RFC 9270

Errata ID: 3304
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Lyndon Ong
Date Reported: 2012-07-31
Rejected by: Adrian Farrel
Date Rejected: 2012-08-09

Section 11 & 12 says:

Section 11 says:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.

Section 12 says:

   [No text on reversion for (full) LSP Rerouting.]

It should say:

Section 11 should say:


   (Full) LSP rerouting will be initiated by the head-end node that has
   either detected the LSP failure or received a Notify message and/or a
   PathErr message with the new error code/sub-code "Notify Error/LSP
   Locally Failed" for this LSP.  The new LSP resources can be
   established using the make-before-break mechanism, where the new LSP
   is set up before the old LSP is torn down.  This is done by using the
   mechanisms of the SESSION_ATTRIBUTE object and the Shared-Explicit
   (SE) reservation style (see [RFC3209]).  Both the new and old LSPs
   can share resources at common nodes.  The new LSP can be established
   without tearing down the old LSP in case of reversion (see section 12).

Section 12 should say:

   For "(full) LSP Rerouting", reversion implies that the old LSP is not 
   torn down by the head-end node after the new LSP is established. For
   reversion, the head-end node re-activates the old LSP after this has
   recovered.

Notes:

Current text in RFC 4872 describes reversion in the cases of 1+1 bidirectional Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra Traffic, however it has no description of reversion with (Full) LSP Rerouting.
For (full) LSP Rerouting, the description in Section 11 instead implies that the old LSP is torn down. This has led to some confusion as to whether reversion with (full) LSP Rerouting is allowed or not allowed by the RFC. We believe this was not intentional. The additions would make it clear that reversion can be supported with (Full) LSP Rerouting.
--VERIFIER NOTES--
After discussions on the CCAMP mailing list it is the general opinion of the CCAMP WG that there is no technical issue and that if any WG participants wish to document how the current mechanisms can be used to support a particular usage/application that they are free to do so in a new informational draft.

Report New Errata