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

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 1 Aug 2012 09:47:14 -0400

Hi Adrian,

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.

>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 (or to require that the old LSP always be torn down in full rerouting), so hopefully with some more discussion we can determine if there is anything that could be done to make that clearer.

Best regards,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, July 31, 2012 6:28 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; 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:[email-masked]]
> Sent: 31 July 2012 17:39
> To: [email-masked]; [email-masked]; dimitri.papadimitriou@alcatel- 
> lucent.be; [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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 <[email-masked]>
> 
> 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

---

From: John E Drake <[email-masked]>
Date: Wed, 1 Aug 2012 07:07:31 -0700

I don't see any problem with the existing text.

Sent from my iPhone

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adrian Farrel
> Cc: [email-masked]; [email-masked];
> [email-masked]
> 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.
> 
> 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:
> *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.
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Wed, 1 Aug 2012 17:07:57 +0200

Hi, 

I agree with the conclusion here below.

Thanks,
-dimitri. 

> Sent: Wednesday, August 01, 2012 03:28
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Papadimitriou, 
> Dimitri (Dimitri); [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> 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
> In my opinion, this proposal goes further than the intention 
> of the authors/WG
> in publishing 4872.
> 
> 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
> 
> 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.
> 
> > The following errata report has been submitted for RFC4872,
> > "RSVP-TE Extensions in Support of End-to-End Generalized 
> Multi-Protocol Label
> > 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,
> > 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:
> > -------------
> > 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.
> >

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 1 Aug 2012 19:01:49 +0100

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
> Cc: [email-masked]; [email-masked]; dimitri.papadimitriou@alcatel-
> lucent.be; [email-masked]; [email-masked]; [email-masked]; Ong,
> Lyndon
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.
> 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
> a. protection may fail because of lack of resources b. reversion may fail
because
> of lack of resources
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?
> 
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.
>

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 1 Aug 2012 17:45:44 -0400

Hi Adrian,

Sorry, not so fast!  Let me make another proposal:

Section 11: 
Existing: 
   is set up before the old LSP is torn down.  

New:
   is set up *while the old LSP is still in place*.  

Reasoning: No longer implies that the old LSP would necessarily be torn down.

Note the text in Section 12 states
   Reversion refers to a recovery switching operation, where the normal
   traffic returns to (or remains on) the working LSP when it has
   recovered from the failure.  *Reversion implies that resources remain
   allocated to the LSP that was originally routed over them even after
   a failure*.  It is important to have mechanisms that allow reversion
   to be performed with minimal service disruption and reconfiguration.

That could be interpreted to rule out Reversion with LSP Rerouting if you must tear down the old LSP.
Of course this could be fixed also (for example by deleting the statement).

Thanks,

Lyndon

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 11:02 AM
To: Ong, Lyndon; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Roch, Evelyne
Subject: RE: [Technical Errata Reported] RFC4872 (3304)

Hello again,

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.

the
allowed

Definitely not the intent to imply that reversion with full rerouting is not allowed.
Does the text say or even imply 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
> lucent.be; [email-masked]; [email-masked]; [email-masked]; 
> Ong, Lyndon
supplied text
handle the
in
> established without tearing down
the
> think
that
perform
find
at all
nature of
because
important.
> If protection is important then you should be using a proper 
> Furthermore, if you
require
> that the LSP be retained for restoration, why are you not using a 
> protection mechanism?
> 
available LSP
after
> to
switch
is
> > To: [email-masked]; [email-masked]; 
> > dimitri.papadimitriou@alcatel- lucent.be; [email-masked]; 
> > [email-masked]; [email-masked]; [email-masked]
> > (full) LSP Rerouting is allowed or not allowed by the RFC. We 
> > believe this was
> not

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Aug 2012 00:10:49 +0100

My personal opinion at this point is that you are proposing wordsmithing that
would have been accepted during document development, but which is not necessary
at this stage.

Any misunderstanding in reading this document is due to an over-enthusiastic
legalistic reading of the text and not an understanding of the technology.

Adrian

> From: Ong, Lyndon [mailto:[email-masked]]
> Sent: 01 August 2012 22:46
> To: [email-masked]; [email-masked]
> lucent.be; [email-masked]; [email-masked]; [email-masked]; Roch,
> Evelyne
> lucent.be; [email-masked]; [email-masked]; [email-masked]; Roch,
> Evelyne
working
> LSP. Also that you have no intention to remove the option of removing the old
> working LSP.
> 
allowed.
> 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?

---

From: John E Drake <[email-masked]>
Date: Wed, 1 Aug 2012 16:49:10 -0700

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

> To: 'Ong, Lyndon'; [email-masked]
> 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.
> 
> 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
> > for. If this get contentious, I will call on Stewart to call
> consensus
> > and
> handle the
> > Erratum in the system.
> >
> > So I conclude that the proposed addition to section 12 is not what
> the
> > authors/WG intended.
> >
> rejected.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 2 Aug 2012 00:40:08 +0000

Hi Adrian- 

Please see comments in-line. 

Thanks

Regards ... Zafar 

> Sent: Tuesday, July 31, 2012 9:28 PM
> To: [email-masked]
> supplied
> text for. If this get contentious, I will call on Stewart to call
> consensus and
> handle the Erratum in the system.
> 
> 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".
> 
> think that
> 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,

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

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.  

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

> available
> LSP when it is set up in the first place, the best available LSP when
> you

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. 

> to switch
> > "RSVP-TE Extensions in Support of End-to-End Generalized Multi-
> Protocol Label
> bidirectional
> > Protection, 1:N Protection with Extra Traffic and Rerouting Without
> Extra
> Traffic,

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 2 Aug 2012 00:48:10 +0000

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 

> Of John E Drake
> Sent: Wednesday, August 01, 2012 7:49 PM
> To: [email-masked]; 'Ong, Lyndon'; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]
> > > different from the issue of the protection LSP itself. That is, it
> is
> > > of the
> > nature of
> > > when it is set up in the first place, the best available LSP when
> you
> > > re-route
> > after
> > > >    (Full) LSP rerouting will be initiated by the head-end node
> that
> > has
> > > >    established using the make-before-break mechanism, where the
> new
> > LSP
> > > >    (Full) LSP rerouting will be initiated by the head-end node
> that
> > has
> > > >    established using the make-before-break mechanism, where the
> new
> > LSP
> > > >    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
> > > > -----

---

From: John E Drake <[email-masked]>
Date: Wed, 1 Aug 2012 17:54:06 -0700

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

> From: Zafar Ali (zali) [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2012 5:48 PM
> To: John E Drake; [email-masked]; 'Ong, Lyndon'; [email-masked]
> Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)
> 
> Hi John-
> 
> > 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
> >
> >
> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Adrian Farrel
> > > 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
> > > > 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
> > > > lucent.be; [email-masked]; [email-masked];
> > > > [email-masked]; Ong, Lyndon
> > > > I find that this erratum is raised against two sections one of
> > > > which
> > > I
> > > supplied text
> > > > The use of mb4b is already in scope. The existing text says "The
> > > > new LSP resources can be established using the make-before-break
> down.
> > I
> > > > > "RSVP-
> > > TE
> > > > >    (SE) reservation style (see [RFC3209]).  Both the new and
> old
> > > LSPs
> > > > >    (SE) reservation style (see [RFC3209]).  Both the new and
> old
> > > LSPs
> > > > >    For "(full) LSP Rerouting", reversion implies that the old
> > > > > LSP
> > > is not
> > > > > intentional. The additions would make it clear that reversion
> > > > > can
> > > be
> > > > > When a decision is reached, the verifying party (IESG) can log
> > > > > in
> > > to
> > > > > Title               : RSVP-TE Extensions in Support of End-to-
> End
> > > Generalized
> > > > Multi-

---

From: Lou Berger <[email-masked]>
Date: Wed, 01 Aug 2012 18:13:04 -0700

> There is, of course, a lot that could be done to make it clearer. But
is there
> 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

---

From: Lou Berger <[email-masked]>
Date: Wed, 01 Aug 2012 14:44:58 -0700

is there

Comments/thoughts?

Lou

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 1 Aug 2012 21:28:29 -0400

That sounds like it might be a good direction to me.

Cheers,

Lyndon

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 2:45 PM
To: [email-masked]; Ong, Lyndon
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Roch, Evelyne
Subject: Re: [Technical Errata Reported] RFC4872 (3304)

is there

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:
>> full rerouting when it is very possible to support a form of 
>> reversion that doesn't involve maintaining the old LSP.
> 
>> Cc: [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; Ong, Lyndon
>> the authors/WG intended.

---

From: Sidd Aanand <[email-masked]>
Date: Thu, 2 Aug 2012 04:06:24 +0000

FWIW, I agree too -- I don't see any issues with the current text.

Thanks,
Sidd

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Wednesday, August 01, 2012 7:38 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Sent from my iPhone

> be impossible to perform reversion because, after repair, an attempt 
> to revert (also using mb4b) might find that key resources have been 
> the issue of the protection LSP itself. That is, it is of the nature 
> of LSP Rerouting as a protection mechanism that:
> *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.
> understand that there is an implication that it might be expected to 
> be torn down.
> 
> dimitri.papadimitriou@alcatel-
> > lucent.be; [email-masked]; [email-masked]; 
> > [email-masked]; [email-masked]
> >    without tearing down the old LSP in case of reversion (see 
> > section
> 12).
> >
> > Section 12 should say:
> >

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 2 Aug 2012 09:11:22 +0000

Hi John/ Adrian, et al- 

Please see in-line. 

Thanks

Regards ... Zafar 

> From: John E Drake [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2012 8:54 PM
> To: Zafar Ali (zali); [email-masked]; 'Ong, Lyndon'; [email-masked]
> 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. 

> > Behalf
> > > > reversion
> > > > > reversion because, after repair, an attempt to revert (also
> using
> > > > > mb4b) might
> > > > find
> > > > > >    either detected the LSP failure or received a Notify
> message
> > > > and/or a
> > > > > >    either detected the LSP failure or received a Notify
> message
> > > > and/or a
> > > > section 12).
> instead

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 2 Aug 2012 10:45:18 -0400

Hi Zafar,

I noted that section of the text as well.

Cheers,

Lyndon

-----Original Message-----
From: Zafar Ali (zali) [mailto:[email-masked]]
Sent: Thursday, August 02, 2012 2:11 AM
To: John E Drake; [email-masked]; Ong, Lyndon; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Hi John/ Adrian, et al-

Please see in-line.

Thanks

Regards ... Zafar

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

> > Please see my response to Adrian's email for the use case for
> > keeping the original LSP around during failure.
> >
> > Thanks
> >
> > Regards ... Zafar
> >
> >
> > > > > suggested has ended up overspecifying the method to do
> > > > > reversion
> > > with
> > > > 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.
> > > >
> > > > 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.
> > > >
> > > > > "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".
> > > > >
> > > > > different from the issue of the protection LSP itself. That
> > > > > is,
> > it
> > > is
> > > > > of the
> > > > nature of
> > > > > that the LSP be retained for restoration, why are you not
> > > > > using
> a
> > > > > protection mechanism?
> > > > >
> > > best
> > > > order
> > > > > > dimitri.papadimitriou@alcatel- lucent.be;
> > > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > > [email-masked]
> > > > > > Extensions in Support of End-to-End Generalized
> > > > > > Multi-Protocol
> > > > Label
> > > > > >    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
> > > > > >    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
> > > > > >    For "(full) LSP Rerouting", reversion implies that the
> > > > > > old LSP
> > > > is not
> > > > > > reversion can
> > > > > > When a decision is reached, the verifying party (IESG) can
> > > > > > log in
> > > > to

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Thu, 2 Aug 2012 17:24:01 +0200

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.

Thanks,
-dimitri.
> Sent: Wednesday, August 01, 2012 23:45
> To: [email-masked]; 'Ong, Lyndon'
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Papadimitriou, Dimitri (Dimitri); [email-masked]; 
> [email-masked]; 'Roch, Evelyne'
> > really a need? We discussed the point. We agreed it is not 
> prohibited
> in the
> reversion with full
> retaining the old
> mechanism," so there
> using a protection
> >> So I conclude that the proposed addition to section 12 is 
> not what the
> >> authors/WG intended.
> >>
> message and/or a
> Shared-Explicit
> message and/or a
> Shared-Explicit
> old LSP is not
> established. For
> reversion can be

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 2 Aug 2012 15:47:05 +0000

Dimitri- 

Please see in-line. 

Thanks

Regards ... Zafar 

> Of Papadimitriou, Dimitri (Dimitri)
> Sent: Thursday, August 02, 2012 11:24 AM
> To: Lou Berger; [email-masked]; 'Ong, Lyndon'
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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).

---

From: Rajan Rao <[email-masked]>
Date: Thu, 2 Aug 2012 16:20:54 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Wednesday, August 01, 2012 5:54 PM
To: Zafar Ali (zali); [email-masked]; 'Ong, Lyndon'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Sent from my iPhone

> > > 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
> > > > that the LSP be retained for restoration, why are you not using 
> > > > a protection mechanism?
> > > >
> > > > > bidirectional Protection, 1:N Protection with Extra Traffic 
> > > > > and Rerouting Without Extra
> > > > Traffic,

---

From: Bijan Jabbari <[email-masked]>
Date: Thu, 02 Aug 2012 12:20:58 -0400

Furthermore, the mechanism to restore to the original LSP should be a
primary option or mode of operation for an operator to exercise. And, it
should not be done via a work-around solution.

There are other protocols in use today which refer to this as "change-back
after failure" and
this mode is widely deployed.

I am not sure how widely this RFC is practiced! I doubt it is
significantly deployed, if any at this time. However, this
may be used widely in the future. So why not fix it now properly.

 Best,
  - Bijan 

On 8/2/12 11:47 AM, "Zafar Ali (zali)" <[email-masked]> wrote:

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 2 Aug 2012 12:26:59 -0400

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:[email-masked]] 
Sent: Thursday, August 02, 2012 8:47 AM
To: Papadimitriou, Dimitri (Dimitri); Lou Berger; [email-masked]; Ong, Lyndon
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Technical Errata Reported] RFC4872 (3304)

Dimitri- 

Please see in-line. 

Thanks

Regards ... Zafar 

> after establishment of the new LSP using make-before-break/RFC 3209) 
> and more robust. see also RFC 4428 for more details.
> 

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

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Aug 2012 09:51:47 -0700

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

> From: Rajan Rao [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 9:21 AM
> To: John E Drake; Zafar Ali (zali); [email-masked]; 'Ong, Lyndon';
> [email-masked]
> Revertive restoration requires keeping original path  because
> continuous monitoring of failed path is necessary for revertive
> operation upon recovery.
>
> Thanks
> Rajan
>
> > > > > Thank you for the fast evaluation of the errata.  It sounds
> like
> > > > > the
> > > > correction that I
> retaining
> "The
> > > > > that key resources have been "stolen" by some other LSP. I
> don't
> > > > > see this as
> > > > at all
> > > > > 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.
> > > > > > Extensions in Support of End-to-End Generalized Multi-
> Protocol
> > > > Label
> whether
> log

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Aug 2012 09:54:28 -0700

Lyndon,

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

Thanks,

John

Sent from my iPhone

> Of Ong, Lyndon
> Sent: Thursday, August 02, 2012 9:27 AM
> To: Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger;
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> 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.
> > > So it sounds like there's agreement that there's no technical
> errata
> > > here.
> > >
> > > don't see this as
> > > reversion may fail
> > > protection is not

---

From: Rajan Rao <[email-masked]>
Date: Thu, 2 Aug 2012 17:18:45 +0000

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:[email-masked]] 
Sent: Thursday, August 02, 2012 9:52 AM
To: Rajan Rao; Zafar Ali (zali); [email-masked]; 'Ong, Lyndon'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Rajan,

Thanks,

John

Sent from my iPhone

> To: John E Drake; Zafar Ali (zali); [email-masked]; 'Ong, 
> Lyndon'; [email-masked]
> > > > > mechanism," so there is no need to re-state "The new LSP can 
> > > > > be established without tearing down
> > > > the
> > > > > old LSP".
> > > > >
> > > > > using a protection mechanism?
> > > > >

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 2 Aug 2012 13:27:36 -0400

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:[email-masked]]
Sent: Thursday, August 02, 2012 9:54 AM
To: Ong, Lyndon; Zafar Ali (zali); Papadimitriou, Dimitri (Dimitri); Lou Berger; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Technical Errata Reported] RFC4872 (3304)

Lyndon,

Thanks,

John

Sent from my iPhone

> > -> so I am not sure to which revision placeholder of RFC 4872 you
> > -> are
> 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

---

From: Lou Berger <[email-masked]>
Date: Thu, 02 Aug 2012 09:34:25 -0700

Dimitri,
	(hat off) while it is not explicit, there is nothing in the draft that
precludes it and some of us certainly reviewed the document at the time
with this in mind to ensure it wasn't.  Furthermore, as we heard in
Paris, there is at least one deployed implementation that implements
reversion with full LSP rerouting.

Based on the level of discussion, I suspect an info doc may be a better
way to go on this topic...

Lou

On 8/2/2012 8:24 AM, Papadimitriou, Dimitri (Dimitri) wrote:
> 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.
> 
>> errata here.

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Aug 2012 10:48:43 -0700

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

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 2 Aug 2012 11:01:12 -0700

It also occurs to me that the text you cited, although problematic, clearly addresses Lyndon's initial erratum.

Sent from my iPhone

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Aug 2012 21:56:00 +0100

Zafar,

[snip]

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

Hmmm.

You are saying that when the initial LSP is established it is OK to use and ERO
to "force" it down the path you want. You are not saying that the network
resources must be pre-reserved for the initial LSP.

Why is it not good enough to use an ERO to "force" reversion?

[BTW: the discussion of whether you might want to do it (that we are having now)
is orthogonal to whether it is possible. I have no issue that it is possible,
and I don't think any changes are needed to any documents to enable it or to say
that it is possible.]

Adrian

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 2 Aug 2012 21:12:43 +0000

Hi Adrian- 

Please see in-line. 

Thanks

Regards ... Zafar 

> Sent: Thursday, August 02, 2012 4:56 PM
> To: Zafar Ali (zali); [email-masked]

I did not understand what you meant by "use an ERO to "force" reversion". The issue in my mind is as follows: 

1. We are at time t0. 
2. Working LSP is setup on THE nominal path (P) with setup/ holder priority (s,h). For simplicity assume P is explicitly configured by SP. 
3. At time t1 > t0, a resource, say link L fails, along the nominal Path (P). 
4. Ingress tears down working LSP. 
5. A restore LSP or protecting LSP starts to carry traffic. 
6. Link L comes back up at t2 > t1. 
7. Some other LSP(s) with setup/ hold priority better than working LSP setup/ holder priority (s,h) claims resources from L. 
8. Nominal Path P is no longer available for working LSP and this is the only Path SP wants the working LSP to take. 
9. Reversion cannot be applied as working LSP stays down. 

Thanks

Regards... Zafar

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Aug 2012 22:32:34 +0100

Oh dear.

First, let me re-assert...

The discussion of whether you might want to do it (that we are having now) is
orthogonal to whether it is possible. I have no issue that it is possible, and I
don't think any changes are needed to any documents to enable it or to say that
it is possible. 

Now to your details...

> 1. We are at time t0.
> 2. Working LSP is setup on THE nominal path (P) with setup/ holder
> priority (s,h). For simplicity assume P is explicitly configured by SP.

Better not?
You do this and you are not doing mb4b.

> 7. Some other LSP(s) with setup/ hold priority better than working
> LSP setup/holder priority (s,h) claims resources from L.
> 8. Nominal Path P is no longer available for working LSP and this is the
> only Path SP wants the working LSP to take.

If the setup/holding priorities are higher, then these new LSPs would take the
resources in any case.
Probably, the interesting case for you is that the new LSPs have identical
(s,h).

> 9. Reversion cannot be applied as working LSP stays down.

Correct.

Now consider...

1a. We are at time t0.
2a. Some other LSP(s) with setup/ hold priority better than working
LSP setup/holder priority (s,h) claims resources from L.
3a. Working LSP is attempted on THE nominal path (P) with setup/ holder
priority (s,h).
4a. Nominal Path P is no longer available for working LSP and this is the
only Path SP wants the working LSP to take.
5a. Service cannot be set up as working LSP stays down.

My point being: when you decided that you did not want to use protection, you
signed up to a particular service level. Of course you would like to apply
reversion, but it is not essential.

Alternatively, when you decided to allow other LSPs to be able to use "your"
network resources, you signed up to a way of operating your network where that
can happen.

A

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 2 Aug 2012 18:18:28 -0400

Hi Adrian,

I'm glad that you say that this (LSP rerouting with reversion) is possible within the existing text, hopefully we can all accept this as conclusive.
Probably this issue would have been clearer if there was a formal definition of "implies" in RFC 2119!

Cheers,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: Thursday, August 02, 2012 2:33 PM
To: 'Zafar Ali (zali)'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [CCAMP] [Technical Errata Reported] RFC4872 (3304)

Oh dear.

The discussion of whether you might want to do it (that we are having now) is orthogonal to whether it is possible. I have no issue that it is possible, and I don't think any changes are needed to any documents to enable it or to say that it is possible. 

Now to your details...

Better not?

> 7. Some other LSP(s) with setup/ hold priority better than working LSP 
> setup/holder priority (s,h) claims resources from L.
> 8. Nominal Path P is no longer available for working LSP and this is 
> the only Path SP wants the working LSP to take.

If the setup/holding priorities are higher, then these new LSPs would take the resources in any case.
Probably, the interesting case for you is that the new LSPs have identical (s,h).

Correct.

Now consider...

1a. We are at time t0.
2a. Some other LSP(s) with setup/ hold priority better than working LSP setup/holder priority (s,h) claims resources from L.
3a. Working LSP is attempted on THE nominal path (P) with setup/ holder priority (s,h).
4a. Nominal Path P is no longer available for working LSP and this is the only Path SP wants the working LSP to take.
5a. Service cannot be set up as working LSP stays down.

My point being: when you decided that you did not want to use protection, you signed up to a particular service level. Of course you would like to apply reversion, but it is not essential.

Alternatively, when you decided to allow other LSPs to be able to use "your"
network resources, you signed up to a way of operating your network where that can happen.

A

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Aug 2012 23:31:23 +0100

Lyndon,

That all depends on what you mean by "in".

A

> Sent: 02 August 2012 23:18
> To: [email-masked]; 'Zafar Ali (zali)'; [email-masked]
> I'm glad that you say that this (LSP rerouting with reversion) is possible
within the
> existing text, hopefully we can all accept this as conclusive.
> Probably this issue would have been clearer if there was a formal definition
of
> "implies" in RFC 2119!
> orthogonal to whether it is possible. I have no issue that it is possible, and
I don't
> think any changes are needed to any documents to enable it or to say that it
is
> possible.
(s,h).
> 2a. Some other LSP(s) with setup/ hold priority better than working LSP
priority
> (s,h).
> 4a. Nominal Path P is no longer available for working LSP and this is the only
Path
> SP wants the working LSP to take.

---

From: Julien Meuric <[email-masked]>
Date: Fri, 03 Aug 2012 01:28:16 +0200

Hi Dimitri.

The initial trigger of the discussion has been resolved, but I wanted to 
comment your introspection below.

Whether it is revertive or not (as said by Zafar), LSP rerouting 
"increases recovery time" with respect to 1+1 protection, but 
*decreases* resource consumption with respect to 1+1. Thus the rationale 
for LSP rerouting at large.

Resource consumption increases only (slightly) when you compare 
non-revertive rerouting with revertive rerouting. This over-consumption 
is only true during failure time, which is not supposed to be a long 
situation. Minimizing this short-life over-consumption is usually not a 
requirement, while reversion (very) often is.

My 2 (Canadian) cents,

Julien

Le 02/08/2012 17:24, Papadimitriou, Dimitri (Dimitri) a écrit :
> I miss the rationales for a "scenario" that increases recovery time*and*  resource consumption.

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Fri, 3 Aug 2012 09:36:12 +0000

Hi Adrian- 

Please see in-line. 

Thanks

Regards ... Zafar 

> Sent: Thursday, August 02, 2012 5:33 PM

Yes, agreed! 

<Snipped to avoid further side-track discussion>

---

From: Lou Berger <[email-masked]>
Date: Fri, 03 Aug 2012 17:26:15 -0400

All,
	Based on the discussion in response to this Errata, the chairs
recommend that (a) this Errata be closed/rejected as it is the general
opinion of the WG that there is no technical issue and that (b) if any
WG participants wish to document how the current mechanisms can be used
to support a particular usage/application that they are free to do so in
a new informational draft.

Thank you,
Deborah and Lou

On 7/31/2012 12:39 PM, RFC Errata System wrote:
> "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery".
> 
> 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:
> -------------
> Title               : RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 Aug 2012 22:27:55 +0100

Thanks Lou,

I'll let this sit in the WG for a couple of days and then take action.

Adrian

> Sent: 03 August 2012 22:26
> To: RFC Errata System
> lucent.be; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> > "RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol
Label
bidirectional
> Protection, 1:N Protection with Extra Traffic and Rerouting Without Extra
Traffic,
> > 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
> > Title               : RSVP-TE Extensions in Support of End-to-End
Generalized Multi-