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

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

Lou, 

there is by definition no notion of "reversion" in full LSP re-routing. this is why there is no such description: it is less faster than e.g. protection but less resource-consuming (direct release of resources after establishment of the new LSP using make-before-break/RFC 3209) and more robust. see also RFC 4428 for more details. 

-> so I am not sure to which revision placeholder of RFC 4872 you are talking as I miss the rationales for a "scenario" that increases recovery time *and* resource consumption.

Thanks,
-dimitri.
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: Wednesday, August 01, 2012 23:45
> To: [e-mail]; 'Ong, Lyndon'
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> Papadimitriou, Dimitri (Dimitri); [e-mail]; 
> [e-mail]; 'Roch, Evelyne'
> Subject: Re: [Technical Errata Reported] RFC4872 (3304)
> 
> > There is, of course, a lot that could be done to make it 
> clearer. But
> is there
> > really a need? We discussed the point. We agreed it is not 
> prohibited
> in the
> > RFC. Can we not just move on?
> 
> So it sounds like there's agreement that there's no technical 
> errata here.
> 
> Perhaps an alternate way to proceed is to replace this errata with an
> editorial errata that states that a future revision of the RFC should
> explicitly discuss how this scenario is covered?
> 
> Comments/thoughts?
> 
> Lou
> 
> On 8/1/2012 11:01 AM, Adrian Farrel wrote:
> > Hello again,
> > 
> >> Thank you for the fast evaluation of the errata.  It 
> sounds like the
> > correction that I
> >> suggested has ended up overspecifying the method to do 
> reversion with full
> >> rerouting when it is very possible to support a form of 
> reversion that doesn't
> >> involve maintaining the old LSP.
> > 
> > Right, I understand that you want to allow the option of 
> retaining the old
> > working LSP. Also that you have no intention to remove the 
> option of removing
> > the old working LSP.
> > 
> >> From your response I believe that you do agree that it was 
> not the intent of
> > the
> >> original specification text to imply that reversion with 
> full rerouting is not
> > allowed
> > 
> > Definitely not the intent to imply that reversion with full 
> rerouting is not
> > allowed.
> > Does the text say or even imply this?
> > 
> >> (or to require that the old LSP always be torn down in 
> full rerouting)
> > 
> > Also no intention to *require* the old LSP to be torn down. 
> > My view is that the text is fully conformant with that.
> > I understand that the text does not make an explicit 
> statement of this.
> > 
> >> so hopefully
> >> with some more discussion we can determine if there is 
> anything that could be
> >> done to make that clearer.
> > 
> > There is, of course, a lot that could be done to make it 
> clearer. But is there
> > really a need? We discussed the point. We agreed it is not 
> prohibited in the
> > RFC. Can we not just move on?
> > 
> > Cheers,
> > Adrian
> >> -----Original Message-----
> >> From: Adrian Farrel [mailto:[e-mail]]
> >> Sent: Tuesday, July 31, 2012 6:28 PM
> >> To: [e-mail]
> >> Cc: [e-mail]; [e-mail]; 
> dimitri.papadimitriou@alcatel-
> >> lucent.be; [e-mail]; [e-mail]; 
> [e-mail]; Ong,
> >> Lyndon
> >> 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
> > 
> > 
> > 
> > 
> > 
>