RE: shared mesh restoration - e2e recovery signaling draft

Dimitri.Papadimitriou@alcatel.be Tue, 25 July 2006 22:56 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5VpR-0005fc-SF for ccamp-archive@ietf.org; Tue, 25 Jul 2006 18:56:41 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5VpQ-0002qu-GV for ccamp-archive@ietf.org; Tue, 25 Jul 2006 18:56:41 -0400
Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1G5Vm7-0005IA-MQ for ccamp-data@psg.com; Tue, 25 Jul 2006 22:53:15 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,NO_REAL_NAME autolearn=no version=3.1.1
Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from <Dimitri.Papadimitriou@alcatel.be>) id 1G5Vm6-0005FR-PO; Tue, 25 Jul 2006 22:53:15 +0000
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k6PMqnV5012494; Wed, 26 Jul 2006 00:52:49 +0200
In-Reply-To: <009f01c6b03c$5b7aab10$30fea8c0@NETPTORAB>
To: Payam Torab <ptorab@lopsys.com>
Cc: ccamp@ops.ietf.org, 'Dave Walters' <dwalters@lopsys.com>, owner-ccamp@ops.ietf.org
Subject: RE: shared mesh restoration - e2e recovery signaling draft
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF0B839290.70AA0157-ONC12571B6.007D67EA-C12571B6.007DAED8@netfr.alcatel.fr>
From: Dimitri.Papadimitriou@alcatel.be
Date: Wed, 26 Jul 2006 00:52:46 +0200
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/26/2006 00:52:48, Serialize complete at 07/26/2006 00:52:48
Content-Type: text/plain; charset="US-ASCII"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4

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
>