RE: shared mesh restoration - e2e recovery signaling draft

[Dimitri.Papadimitriou@alcatel.be]

notify the other (N-1) ingresses by sending a PathErr of Notify msg - the 
error code defined for this case is "Notify Error/LSP Recovered" - applies 
here, i didn't list it in the draft because the mechanism of bringing back 
the recovery LSP availability is not specific to shared mesh it applies 
whenever the recovery LSP is not available for whatever reason

thanks,
- d.





"Payam Torab" <ptorab@lopsys.com>
Sent by: owner-ccamp@ops.ietf.org
26/07/2006 01:11
 
        To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
        cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
<dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
        Subject:        RE: shared mesh restoration - e2e recovery 
signaling draft


Dimitri- indeed, the last case under Section 12 is the case of interest, 
but
we are talking about the very last step of the process (last two sentences
in Section 12):

   3. Finally, de-activate the protecting LSP by setting the S bit to 1 
      in the PROTECTION object sent over the protecting LSP.

It is not clear (not documented) how the ingress nodes for other working
LSPs should know after this step that the protecting LSP is available 
again
and they are not vulnerable anymore. I hope this clarifies the question.

Thanks,
Payam


> -----Original Message-----
> From: Dimitri.Papadimitriou@alcatel.be 
> [mailto:Dimitri.Papadimitriou@alcatel.be] 
> Sent: Tuesday, July 25, 2006 6:53 PM
> To: Payam Torab
> Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> Subject: RE: shared mesh restoration - e2e recovery signaling draft
> 
> 
> ok you are referring to the case when the LSP reverts back to 
> the primary same business but instead make use of the "Notify 
> Error/LSP Recovered" 
> code
> 
> this is documented in section 12 (last part)
> 
> thanks,
> - dimitri.
> 
> 
> 
> 
> "Payam Torab" <ptorab@lopsys.com>
> Sent by: owner-ccamp@ops.ietf.org
> 26/07/2006 00:47
> 
>         To:     Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
>         cc:     <ccamp@ops.ietf.org>, "'Dave Walters'" 
> <dwalters@lopsys.com>, <owner-ccamp@ops.ietf.org>
>         Subject:        RE: shared mesh restoration - e2e recovery 
> signaling draft
> 
> 
> The question is availability of a mechanism once the shared 
> restoration 
> path
> becomes available again - we would like to let the other 
> ingress nodes 
> know
> their LSPs are no longer vulnerable (if they have not picked 
> a different restoration path already); Referring to the 
> scenario on page 20 of the draft, it is desirable for node E 
> to notify H that the shared restoration path H-E-F-G-K is 
> available again.
> 
> A notify message with the error code/sub-code "Notify 
> Error/LSP Recovered" could be a good solution, but it does 
> not seem to be used by the draft in this context.
> 
> Thanks,
> Payam
> 
> 
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of 
> > Dimitri.Papadimitriou@alcatel.be
> > Sent: Tuesday, July 25, 2006 6:25 PM
> > To: Payam Torab
> > Cc: ccamp@ops.ietf.org; 'Dave Walters'; owner-ccamp@ops.ietf.org
> > Subject: Re: shared mesh restoration - e2e recovery signaling draft
> > 
> > 
> > hi
> > 
> > your question is in a shared mesh case, are the ingress nodes (N-1)
> > notified about the use of the recovery path by the remaining 
> > ingress node 
> > part of the same shared mesh group
> > 
> > answer is yes - you can notify the other ingresses by sending
> > a PathErr of 
> > Notify msg - the error code defined for this case is "Notify 
> > Error/LSP 
> > Locally Failed" - 
> > 
> > much thanks,
> > - dimitri.
> > 
> > 
> > 
> > 
> > 
> > "Payam Torab" <ptorab@lopsys.com>
> > Sent by: owner-ccamp@ops.ietf.org
> > 26/07/2006 00:11
> > 
> >         To:     <ccamp@ops.ietf.org>
> >         cc:     "'Dave Walters'" <dwalters@lopsys.com>
> >         Subject:        shared mesh restoration - e2e 
> > recovery signaling
> > draft
> > 
> > 
> > In the e2e recovery signaling draft
> > (draft-ietf-ccamp-gmpls-recovery-e2e-signaling-03.txt), there is a 
> > procedure defined for a node on the shared restoration path 
> to notify 
> > other nodes regarding the working LSPs that become vulnerable 
> > as a result 
> > of switching to the shared restoration path.
> > 
> > It seems there is a similar need to notify these nodes once
> > the shared 
> > restoration path becomes available again. Is this mechanism defined 
> > anywhere?
> > 
> > Thanks,
> > Payam
> > 
> 
> 
>