[CCAMP] [Technical Errata Reported] RFC4872 (3304)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC4872,
"RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4872&eid=3304

--------------------------------------
Type: Technical
Reported by: Lyndon Ong <[e-mail]>

Section: 11 & 12

Original Text
-------------
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.]

Corrected Text
--------------
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.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4872 (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-04)
--------------------------------------
Title               : RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery
Publication Date    : May 2007
Author(s)           : J.P. Lang, Ed., Y. Rekhter, Ed., D. Papadimitriou, Ed.
Category            : PROPOSED STANDARD
Source              : Common Control and Measurement Plane
Area                : Routing
Stream              : IETF
Verifying Party     : IESG