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

["Adrian Farrel" <[e-mail]>]

Thanks Lou,

I'll let this sit in the WG for a couple of days and then take action.

Adrian

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: 03 August 2012 22:26
> To: RFC Errata System
> Cc: [e-mail]; [e-mail]; dimitri.papadimitriou@alcatel-
> lucent.be; [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: [Technical Errata Reported] RFC4872 (3304)
> 
> 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
> >
> >
> >
> >