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

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

Hi Adrian- 

Please see comments in-line. 

Thanks

Regards ... Zafar 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Adrian Farrel
> Sent: Tuesday, July 31, 2012 9:28 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: [CCAMP] [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
> 

Not if the states for old (working) LSP is kept around during failure. 

> *If* reversion is so important, I don't quite see why protection is not
> important. 

Reversion and Protection are orthogonal to each other. A network may have a requirement for "reversion" for unprotected LSP. These requirements, as you know, come from the Transport world. 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.  

> If protection is important then you should be using a proper
> protection mechanism and not waiting for post facto rerouting.

Again, 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). 

> Furthermore, if
> you require that the LSP be retained for restoration, why are you not
> using a
> protection mechanism?
> 

Again, the option to retain original (working) LSP should not depends on whether circuit is protected or restored on-the-fly.  

> 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".
> 

The original paths in the network may be explicit (with mix of dynamic for other services). In this case, service of a LSP may not come back to the original explicit paths if some other (dynamic) LSP "stole" the resources for the failed working LSP (if resources are released during a failure) - as you noted above. 

> 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