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

["Papadimitriou, Dimitri (Dimitri)" <[e-mail]>]

Hi, 

I agree with the conclusion here below.

Thanks,
-dimitri. 

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]] 
> Sent: Wednesday, August 01, 2012 03:28
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Papadimitriou, 
> Dimitri (Dimitri); [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: RE: [Technical Errata Reported] RFC4872 (3304)
> 
> Hi CCAMP,
> 
> I find that this erratum is raised against two sections one 
> of which I supplied
> text for. If this get contentious, I will call on Stewart to 
> call consensus and
> handle the Erratum in the system.
> 
> In my opinion, this proposal goes further than the intention 
> of the authors/WG
> in publishing 4872.
> 
> With regard to the proposed addition to section 11...
> The use of mb4b is already in scope. The existing text says 
> "The new LSP
> resources can be established using the make-before-break 
> mechanism," so there is
> no need to re-state "The new LSP can be established without 
> tearing down the old
> LSP".
> 
> I think your concern here is whether the old LSP is ever torn 
> down. I think that
> you are worried that if the old LSP is torn down, it might be 
> impossible to
> perform reversion because, after repair, an attempt to revert 
> (also using mb4b)
> might find that key resources have been "stolen" by some 
> other LSP. I don't see
> this as at all different from the issue of the protection LSP 
> itself. That is,
> it is of the nature of LSP Rerouting as a protection mechanism that:
> a. protection may fail because of lack of resources
> b. reversion may fail because of lack of resources
> 
> *If* reversion is so important, I don't quite see why 
> protection is not
> important. If protection is important then you should be 
> using a proper
> protection mechanism and not waiting for post facto 
> rerouting. Furthermore, if
> you require that the LSP be retained for restoration, why are 
> you not using a
> protection mechanism? 
> 
> But the general paradigm here is that you are willing to use 
> the best available
> LSP when it is set up in the first place, the best available 
> LSP when you
> re-route after failure, and the best available LSP when you "revert".
> 
> Lastly, it *does* remain an _option_ to retain the failed LSP 
> in order to switch
> back. Nothing in the old text precludes that, although I 
> understand that there
> is an implication that it might be expected to be torn down.
> 
> So I conclude that the proposed addition to section 12 is not what the
> authors/WG intended.
> 
> We should discuss further.
> 
> Adrian
> 
> > -----Original Message-----
> > From: RFC Errata System [mailto:[e-mail]]
> > Sent: 31 July 2012 17:39
> > To: [e-mail]; [e-mail]; 
> dimitri.papadimitriou@alcatel-
> > lucent.be; [e-mail]; [e-mail]; 
> [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail]; [e-mail]
> > Subject: [Technical Errata Reported] RFC4872 (3304)
> > 
> > 
> > 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
> 
>