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

[Lou Berger <[e-mail]>]

All,
	Based on the discussion in response to this Errata, the chairs
recommend that (a) this Errata be closed/rejected as it is the general
opinion of the WG that there is no technical issue and that (b) 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.

Thank you,
Deborah and Lou

On 7/31/2012 12:39 PM, RFC Errata System wrote:
> 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
> 
> 
> 
>