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

["Zafar Ali (zali)" <[e-mail]>]

Hi John/ Adrian, et al- 

Please see in-line. 

Thanks

Regards ... Zafar 


> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Wednesday, August 01, 2012 8:54 PM
> To: Zafar Ali (zali); [e-mail]; 'Ong, Lyndon'; [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> 
> You can't keep the original, broken LSP around because it no longer has
> e2e committed resources.  The best you can do is clean it up and try to
> re-instantiate it on its original path.
> 

"Section 12.  Reversion" of http://tools.ietf.org/html/rfc4872. 

" Reversion implies that resources remain
   allocated to the LSP that was originally routed over them even after
   a failure." 

So in this case it is required that the original LSP does not release the already committed resource during failure. 

If the node detecting the failure send a Path Error "without" PSR flag and the ingress node does NOT tear LSPs that require the above mentioned behavior, the path and resv states for the original (working) LSP along the nominal path are kept around. 

> Sent from my iPhone
> 
> > -----Original Message-----
> > From: Zafar Ali (zali) [mailto:[e-mail]]
> > Sent: Wednesday, August 01, 2012 5:48 PM
> > To: John E Drake; [e-mail]; 'Ong, Lyndon'; [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> >
> > Hi John-
> >
> > Please see my response to Adrian's email for the use case for keeping
> > the original LSP around during failure.
> >
> > Thanks
> >
> > Regards ... Zafar
> >
> >
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] On
> > Behalf
> > > Of John E Drake
> > > Sent: Wednesday, August 01, 2012 7:49 PM
> > > To: [e-mail]; 'Ong, Lyndon'; [e-mail]
> > > Cc: [e-mail]; [e-mail];
> > > [e-mail]
> > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> > >
> > > Is it not the case that the old LSP is broken?  In which case it
> > needs
> > > to be cleaned up and re-signaled.
> > >
> > > Sent from my iPhone
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail] [mailto:[e-mail]] On
> > > > Behalf Of Adrian Farrel
> > > > Sent: Wednesday, August 01, 2012 11:02 AM
> > > > To: 'Ong, Lyndon'; [e-mail]
> > > > Cc: [e-mail]; [e-mail];
> > > > [e-mail]
> > > > Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> > > >
> > > > 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