amit,
upon control plane failure you apply the mechanisms described in section 9 of RFC 3473 that allows recovery when the data plane has retained the forwarding state across a restart (this covers the case you mention here below when control channel is under failure), in case of source nodal failure you apply the extended restart mechanism described in <draft-ietf-ccamp-rsvp-restart-ext-02.txt> => the LSP is not deleted (if this your question), in the other way around there is no specific issue as resources are retained and the LSP refreshed until data plane failure is recovered
Amit 70405 <AmitG@huawei.com>
Sent by: owner-ccamp@ops.ietf.org
04/06/2005 10:55 ZE8
To: ccamp@ops.ietf.org
cc:
bcc:
Subject: Re: Regarding Reversion
Hi All,
Can anybody plz clarify.
Thanks in advance.
Regards,
Amit.
From Amit 70405 <AmitG@huawei.com>
Sent Monday, April 4, 2005 9:53 am
To Dimitri.Papadimitriou@alcatel.be
Cc ccamp@ops.ietf.org
Bcc
Subject Re: Regarding Reversion
Hi Dimitri,
I saw the details mentioned by you about this in another draft abot e2e recovery.
So the LSP deletion is based on Reresh messages in reversion.
But what will be the case in below scenarios:
1. if there is a dwonstream node fails. In this case refresh messages too will get affected.
2. if the signaling is in-band and the outif(as I mentioned in my previous mail) goes down. And there is no other interface to get the refresh messages.
Plz let me know your view.
Thanks and Regards,
Amit.
From Dimitri.Papadimitriou@alcatel.be
Sent Friday, April 1, 2005 7:51 pm
To Amit 70405 <AmitG@huawei.com>
Cc Dimitri.Papadimitriou@alcatel.be , ccamp@ops.ietf.org
Bcc
Subject Re: Regarding Reversion
amit, upon data plane failure there is no such behaviour as you mention - local data plane failure detection does not imply state deletion and common PathErr/ResvErr do not trigger any state deletion nor does a Notify; in particular, in the present context where one do assume control plane availability even in case of data plane failure - note: details of it available in other documents - states can be kept refreshed
Amit 70405 <AmitG@huawei.com>
Sent by: owner-ccamp@ops.ietf.org
04/01/2005 17:51 ZE8
To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: ccamp@ops.ietf.org
bcc:
Subject: Re: Regarding Reversion
Hi,
Thanks for replying.
According to the statement I mentioned from the draft, I understand that, if there is a failure the old working LSP should not be deleted.
But not only for RSVP, for any MPLS Signaling protocol, it is mandatory that when a failure happens, you should start tearing down the LSP.
Take for instance if a OutInterface(on which LSP is setup) goes down.
Protocol will lead to LSP deletion.
Plz correct me if I am wrong.
Regards,
Amit.
From Dimitri.Papadimitriou@alcatel.be
Sent Friday, April 1, 2005 5:24 pm
To Amit 70405 <AmitG@huawei.com>
Cc ccamp@ops.ietf.org
Bcc
Subject Re: Regarding Reversion
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
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.