Re: Regarding Reversion

[Amit 70405 <AmitG@huawei.com>]

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.

   In both these scenarios, as refresh does not happen, the LSP should get deleted.

   Plz confirm if this is right.

   Or are you going to do some self-refresh kind of for infinite duration.
   Duration should be infinite as recovery of failure may take time.
   This self refresh has to be till failure recovers or till you again start getting the refresh messages. Or the State gets explicitly deleted by head end.

   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.