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 >
- Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- Re: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- Re: Proposed response to OIF on OSPF ENNI Tomohiro Otani
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- Re: Proposed response to OIF on OSPF ENNI Richard Rabbat
- Addressing draft [Was: Proposed response to OIF o… Adrian Farrel
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- Alignment of OIF routing requirements with CCAMP … Adrian Farrel
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Brungard, Deborah A, ALABS
- RE: Proposed response to OIF on OSPF ENNI Sadler, Jonathan B.
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- Re: Proposed response to OIF on OSPF ENNI Adrian Farrel
- An IETF / OIF liaison relationship Was: (Re: Prop… Loa Andersson
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- shared mesh restoration - e2e recovery signaling … Payam Torab
- Re: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: shared mesh restoration - e2e recovery signal… Payam Torab
- RE: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: shared mesh restoration - e2e recovery signal… Payam Torab
- RE: shared mesh restoration - e2e recovery signal… Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Dimitri.Papadimitriou
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI Drake, John E
- RE: Proposed response to OIF on OSPF ENNI Ong, Lyndon
- RE: Proposed response to OIF on OSPF ENNI MEURIC Julien RD-CORE-LAN
- RE: Proposed response to OIF on OSPF ENNI Drake, John E