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

[John E Drake <[e-mail]>]

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