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

[Bijan Jabbari <[e-mail]>]

Furthermore, the mechanism to restore to the original LSP should be a
primary option or mode of operation for an operator to exercise. And, it
should not be done via a work-around solution.

There are other protocols in use today which refer to this as "change-back
after failure" and
this mode is widely deployed.

I am not sure how widely this RFC is practiced! I doubt it is
significantly deployed, if any at this time. However, this
may be used widely in the future. So why not fix it now properly.

 Best,
  - Bijan 




On 8/2/12 11:47 AM, "Zafar Ali (zali)" <[e-mail]> wrote:

>Dimitri- 
>
>Please see in-line.
>
>Thanks
>
>Regards ... Zafar 
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of Papadimitriou, Dimitri (Dimitri)
>> Sent: Thursday, August 02, 2012 11:24 AM
>> To: Lou Berger; [e-mail]; 'Ong, Lyndon'
>> Cc: [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>> 
>> 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.
>> 
>
>Reversion requirement has nothing to do with the "recovery time" or
>"protection" vs. "restoration". Reversion requirement has to do with
>ability for the LSP to come back up on the original path *after* the
>failure is recovered. Typically working LSP follows nominal path (e.g.,
>least latency path) and SPs would like the LSP to go back to nominal LSP
>path once a failure is repair. During failure time, either protection or
>restoration kicks in to minimize impact on the service. Reversion
>requirements equally apply to protection as well as restoration.
>
>For some circuit SP may decide that on-the-fly restoration suffices (may
>be based on monitory cost for the circuit). But they still like the LSP
>to go back to the nominal path (original working path).
>
>> 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
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp