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

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

If I were so inclined, I would file an erratum against the text you cited.

Sent from my iPhone

On Aug 2, 2012, at 10:18 AM, "Rajan Rao" <[e-mail]> wrote:

> John,
>
> I too agree that existing text from Section-12 (see below) is sufficient as pointed by Zafar.  The text below should also clarify your questions.
> "
> For "Rerouting without Extra-traffic" (including the shared recovery
>   case), reversion implies that the formerly working LSP has not been
>   torn down by the head-end node upon PathErr message reception, i.e.,
>   the head-end node kept refreshing the working LSP under failure
>   condition.  This ensures that the exact same resources are retrieved
>   after reversion switching (except if the working LSP required re-
>   signaling).
> "
>
> Thanks
> Rajan
>
>
> -----Original Message-----
> From: John E Drake [mailto:[e-mail]]
> Sent: Thursday, August 02, 2012 9:52 AM
> To: Rajan Rao; Zafar Ali (zali); [e-mail]; 'Ong, Lyndon'; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>
> Rajan,
>
> Due to link and/or node failure the resources of a failed LSP may not be maintained.  Further, at any time a higher priority LSP may be established that pre-empts the resources of a failed LSP.  This is sort of basic.
>
> Also, because of this, I am not sure what the phrase 'continuous monitoring of failed path is necessary' means or how you intend to accomplish this other than by attempting to re-establish the failed LSP along its original path.
>
> Finally, and most importantly, as I indicated yesterday, I don't see anything wrong with the existing text.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>> -----Original Message-----
>> From: Rajan Rao [mailto:[e-mail]]
>> Sent: Thursday, August 02, 2012 9:21 AM
>> To: John E Drake; Zafar Ali (zali); [e-mail]; 'Ong,
>> Lyndon'; [e-mail]
>> Cc: [e-mail]; [e-mail];
>> [e-mail]
>> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
>>
>> John,
>>
>> Revertive restoration requires keeping original path  because
>> continuous monitoring of failed path is necessary for revertive
>> operation upon recovery.
>>
>> Thanks
>> Rajan
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of John E Drake
>> Sent: Wednesday, August 01, 2012 5: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.
>>
>> 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]; rfc-editor@rfc-
>> editor.org
>>>>>>> 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=330
>>>>>>> 4
>>>>>>>
>>>>>>> --------------------------------------
>>>>>>> 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
>> _______________________________________________
>> CCAMP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ccamp