Re: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt

Dan Li <danli@huawei.com> Mon, 05 January 2009 00:10 UTC

Date: Mon, 05 Jan 2009 08:02:13 +0800
From: Dan Li <danli@huawei.com>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt
To: Yechiel Rosengarten <Yechiel.Rosengarten@ecitele.com>, gjhhit@huawei.com, asatyana@cisco.com
Cc: ccamp@ops.ietf.org
Message-id: <007c01c96ec8$dd24f0b0$424d460a@china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
References: <20080519163002.302B93A69FD@core3.amsl.com> <93BC09B2B8795C49B4E3453CE6A45A18894C496ECB@ILPTMAIL02.ecitele.com>
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk

Hi Yechiel,

Sorry for the late reply.

Your question is that Node C SHOULD NOT send RecoveryPath message to Node B, because Node C is a restarting node. 

But I think:
1) According to RFC5063, Node C COULD send RecoveryPath message even it's a restarting node.
2) Node B needs to receive RecoveryPath message from Node C to be recovered.
3) In case of the recovery timer is expired, and the corresponding LSP state of Node B is removed, a PathTear message will be sent to Node C by Node B. 

Please correct me if I was wrong, and if you think any clarification is needed in the draft, please let me know.

Thanks,

Dan

----- Original Message ----- 
From: "Yechiel Rosengarten" <Yechiel.Rosengarten@ecitele.com>
To: <danli@huawei.com>; <gjhhit@huawei.com>; <asatyana@cisco.com>
Cc: <ccamp@ops.ietf.org>
Sent: Tuesday, December 23, 2008 7:28 PM
Subject: RE: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt


Hi
I would like to get some clarification:
By the end of procedure for scenario 1 its written:

   ..... Note that if Node C 
   restarts after this operation, the RecoveryPath message that it 
   sends to Node B will not be matched with any state on Node B and 
   will receive a PathTear as its response resulting in the teardown 
   of the LSP at all downstream nodes.

How comes that node C, which is now the restarting node, sends RecoveryPath that should be sent by downstream normal node and not by restarting node?

Same question for the other scenarios that mention similar behavior.

Best Regards,

Yechiel Rosengarten
System Engineering
ECI Telecom Ltd
30 Hasivim St. Petach Tikva 49517 Israel
Tel:  +972 3 926 8794
Fax: +972 3 926 6200
e-mail: yechiel.rosengarten@ecitele.com

-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, May 19, 2008 7:30 PM
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

        Title           : Description of the RSVP-TE Graceful Restart Procedures
        Author(s)       : D. Li
        Filename        : draft-ietf-ccamp-gr-description-03.txt
        Pages           : 19
        Date            : 2008-5-19

The Hello message for the Resource Reservation Protocol (RSVP) has
   been defined to establish and maintain basic signaling node
   adjacencies for Label Switching Routers (LSRs) participating in a
   Multiprotocol Label Switching (MPLS) traffic engineered (TE)
   network. The Hello message has been extended for use in Generalized
   MPLS (GMPLS) network for state recovery of control channel or nodal
   faults.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gr-description-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

I-D ACTION:draft-ietf-ccamp-gr-description-03.txt Internet-Drafts
RE: I-D ACTION:draft-ietf-ccamp-gr-description-03… Yechiel Rosengarten
Re: I-D ACTION:draft-ietf-ccamp-gr-description-03… Dan Li