Subject: Regarding Reversion

From: Amit 70405 <[email-masked]>
Date: Fri, 01 Apr 2005 14:39:53 +0800

Subject: Regarding Reversion
From: Amit 70405 <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Date: Fri, 01 Apr 2005 14:28:44 +0800

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.

---

From: [email-masked]
Date: Fri, 1 Apr 2005 11:24:44 +0200

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 <[email-masked]>
Sent by: [email-masked]
04/01/2005 14:39 ZE8

To: [email-masked]
cc:
bcc:

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 <[email-masked]>
Subject: Regarding Reversion
To: [email-masked], [email-masked]
Cc: [email-masked]
Message-id: <[email-masked]>
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,

It is said:

---

From: Amit 70405 <[email-masked]>
Date: Fri, 01 Apr 2005 17:51:36 +0800

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: [email-masked]
Date: Fri, 1 Apr 2005 13:51:49 +0200

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

04/01/2005 17:51 ZE8

To: Dimitri PAPADIMITRIOU/BE/ALCATEL@ALCATEL
cc: [email-masked]
bcc:
Subject: Re: Regarding Reversion

Hi,
Thanks for replying.

Content-transfer-encoding: QUOTED-PRINTABLE
MIME-version: 1.0
Content-type: TEXT/PLAIN

¶+'7ÉëJ–¦
œ'êÕz»"¢t©j`,±«,Š}ô×m4ã]6Ú‰é²(™t©jbÞ½éWJ–¦JÖºÃh±Ê+{_ê®Š·çKzËlbKMLÂöÓ}LÂÌ$€AÓ0³0CN3 LŒ Á!:á1LÂ tÌ,ãK`Ó'Í
Â

"
#

R
C£#ƒ£CB³
ƒ

Ä%#äg&öÓ¢Ö—B
s
C
RfÇC´Ö—Dt‡VvV'æ6öÒfwC³Ä%#å7V&¦V7C¢&Vv&F–ær&WfW'6–öãÄ%#åFó¢&Æç&¦v÷Æä–çFVÂæ6öÒÂF–Ö—G&'çF–Ö—G&–÷TÆ6FVÂæ&SÄ%#ä63¢66×–WFbæ÷&sÄ%#äÖW76vRÖ–C¢fÇC³#FCsƒƒ#Fc&fbã#Fc&fc#FCsƒ

---

From: Amit 70405 <[email-masked]>
Date: Mon, 04 Apr 2005 09:53:25 +0800

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: Amit 70405 <[email-masked]>
Date: Wed, 06 Apr 2005 10:55:21 +0800

Hi All,
   Can anybody plz clarify.
   Thanks in advance.
Regards,
Amit.

From   Amit 70405 <[email-masked]>  
Sent  Monday, April 4, 2005 9:53 am 
To  [email-masked]  
Cc  [email-masked]  
Bcc    
Subject  Re: Regarding Reversion 

Hi Dimitri,

From   [email-masked]  
Sent  Friday, April 1, 2005 7:51 pm 
To  Amit 70405 <[email-masked]>  
Cc  [email-masked] , [email-masked]  
Bcc    
Subject  Re: Regarding Reversion 

Hi,
Thanks for replying.

From   [email-masked]  
Sent  Friday, April 1, 2005 5:24 pm 
To  Amit 70405 <[email-masked]>  
Cc  [email-masked]  
Bcc    
Subject  Re: Regarding Reversion 

To: [email-masked]
cc: 
bcc: 

Hi,

It is said:

---

From: [email-masked]
Date: Wed, 6 Apr 2005 09:51:19 +0200

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

04/06/2005 10:55 ZE8

To: [email-masked]
cc:
bcc:

Hi All,
Can anybody plz clarify.
Thanks in advance.
Regards,
Amit.

Hi Dimitri,

Hi,
Thanks for replying.

To: [email-masked]
cc:
bcc:

Hi,

It is said:

---

From: Amit 70405 <[email-masked]>
Date: Wed, 06 Apr 2005 17:05:39 +0800

Hi Dimitri,
   Thanks a lot for replying.

   But depending on GR may lead to below problems:
   - For all the LSP's, on restart(or failure) a notification MAY be sent to the upstream of the LSP about the failure. And if the upstream(Ingress) decides to delete the LSP, then upstream MAY only delete it till the restarted node. Downstream to the Retarted node the LSP will continue to exist as result of GR process till the GR completes.
   - And if a restarting node or the neighbor node doesnt support GR than it will not be possible to retain the LSP.

   Yes but I agree with you that GR can be used for Reversion.
   Thanks a lot again.

Regards,
Amit.