Re: Regarding Reversion

[Dimitri.Papadimitriou@alcatel.be]

hi - would you please clarify your comment - to which potential violation do you refer ? in particular this specification being functional specific details concerning realization using RSVP are provided in the end-to-end signaling document

Amit 70405 <AmitG@huawei.com>
Sent by: owner-ccamp@ops.ietf.org
04/01/2005 14:39 ZE8

To: ccamp@ops.ietf.org
cc:
bcc:
Subject: Regarding Reversion

Content-transfer-encoding: 7BIT
Received: from [172.24.1.3] (Forwarded-For: [10.78.230.163]) by szxmc02-in.huawei.com (mshttpd); Fri, 01 Apr 2005 14:28:44 +0800
Date: Fri, 01 Apr 2005 14:28:44 +0800
From: Amit 70405 <AmitG@huawei.com>
Subject: Regarding Reversion
To: bala.rajagopalan@intel.com, dimitri.papadimitriou@alcatel.be
Cc: ccamp@ietf.org
Message-id: <124d788124f2ff.124f2ff124d788@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar  3 2004)
Content-type: text/plain; charset=us-ascii
Content-language: en
Content-disposition: inline
X-Accept-Language: en
Priority: normal

Hi,
In the draft draft-ietf-ccamp-gmpls-recovery-functional-04.txt, in the section about Reversion.

It is said:
"Reversion implies that a working path remains allocated to the LSP that
was originally routed over it even after a failure."

This requirement may hold true for non-PSC networks, and may not be required in PSC.
How can RSVP support this?? I mean it may totally violate RSVP-TE standard.
As though the failure has happened and LSP should not be deleted.

Plz let me know your view on this.
Regards,
Amit.