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

["Ong, Lyndon" <[e-mail]>]

Hi John,

We may be talking about different things, I was thinking of carriers' management systems for transport networks.  Anyway it's a side point.

Cheers,

Lyndon

-----Original Message-----
From: John E Drake [mailto:[e-mail]]
Sent: Thursday, August 02, 2012 9:54 AM
To: Ong, Lyndon; Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [Technical Errata Reported] RFC4872 (3304)

Lyndon,

As I am sure you remember, that is why graceful restart was invented.

Thanks,

John

Sent from my iPhone


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Ong, Lyndon
> Sent: Thursday, August 02, 2012 9:27 AM
> To: Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger;
> [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>
> I agree with Zafar, I believe that the interest in reversion is due to
> carrier's operational concerns.
>
> Cheers,
>
> Lyndon
>
> -----Original Message-----
> From: Zafar Ali (zali) [mailto:[e-mail]]
> Sent: Thursday, August 02, 2012 8:47 AM
> To: Papadimitriou, Dimitri (Dimitri); Lou Berger; [e-mail];
> Ong, Lyndon
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [Technical Errata Reported] RFC4872 (3304)
>
> 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