[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-gr-description-03.txt
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.