[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,

Hi Jiang,

Yes, I read your I-D when it was published in November last year.
It seems to me that you were addressing a very specific sub-case of the graceful restart problem space. If we generalise to a linear network A-B-C-D-E-F with an LSP running from A to F, your draft handles the case where all four nodes B, C, D and E fail, and C and D subsequently recover, but have retained no LSP state. You are asking the question, how do nodes C and D know to exchange Hello messages.
The reasons why I limit your draft to such a narrow subset of the problem are: 
- If any restarting node is adjacent to a node
 that remained active, the active node will
 send a Hello message and that will engage
 the graceful restart procedures
- If the restarting node had retained any
 LSP state, it would know about its neighbours
 and would be able to send Hello messages.
This seems like a very small corner case, and we do not usually design the protocols to optimise for this type of error condition. So long as there is *a* solution, we are usually happy. That said, if this is a problem that is causing you problems in the field, we should address it.
I note that your I-D has expired and I wonder what your plans are for this work. 

Regards,
Adrian
----- Original Message ----- From: <jiang.weilian@zte.com.cn> 
To: "Olufemi Komolafe" <femi@dcs.gla.ac.uk>
Cc: "ccamp" <ccamp@ops.ietf.org>; <danli@huawei.com>; <gjhhit@huawei.com>; <owner-ccamp@ops.ietf.org> 
Sent: Wednesday, September 20, 2006 3:57 AM
Subject: RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,



Hello, everyone!

We have put forward a mechanism to solve this problem in our
draft "draft-jian-ccamp-multinodes-rsvp-restart-00" last year.

We think that if multiple adjacent nodes restarted nearly at
the same time, these nodes cannot learn about the GR capability
from each other.

The key of this problem is that how restarted node actively
inform its GR(Graceful Restart) capability to neighbor nodes,
especially some neighbor nodes are restarted nodes too.

If you concern our mechanism, please read our draft for detail.




Regard,
Jiang Weilian
...............................................
Add:   No.68 Zijinghua Rd,Yuhuatai District,
       Nanjing. P.R.China.
Zip:   210012
Tel:   0086-25-52871644
Mail:  jiang.weilian@zte.com.cn
.............................................





"Olufemi Komolafe" <femi@dcs.gla.ac.uk>
发件人： owner-ccamp@ops.ietf.org

2006-09-19 20:45

       收件人：        <danli@huawei.com>, <gjhhit@huawei.com>
       抄送：  "ccamp" <ccamp@ops.ietf.org>
       主题：  RE: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,


Hi,

While reading this draft it occurred to me that perhaps it might be more
useful to approach this topic from the perspective of “What can go wrong
during graceful restart, what are the consequences and how can it be
fixed?” rather than focusing on the narrower topic of multiple
simultaneous nodal faults.

For example, Scenario 1 in the draft may be interpreted as “What should
happen if a (non-ingress) restarting node fails to get a RecoveryPath
message from its downstream neighbour?”, Scenario 2 is “What should
happen if a (non-ingress) restarting node fails to get a Path message from
its upstream neighbour?” and so on.  Whether each of these scenarios
arises due to multiple simultaneous nodal faults (as in the draft) or any
other reason (e.g. a subsequent control channel failure, restarting node
being inundated with messages etc.) is, in my opinion, secondary.  I think
the key thing is to identify the potential problems and suggest
appropriate remedial actions, where the authors think existing
documentation is insufficient, rather than focusing on 5 different
permutations of multiple node graceful restart.

Regards,
Femi



From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Zafar Ali (zali)
Sent: 10 July 2006 04:04
To: danli@huawei.com; gjhhit@huawei.com
Cc: ccamp
Subject: Comments on draft-li-ccamp-multinodes-gr-proc-00.txt,

Dear Authors,

This is Deja-vu to me....

Draft draft-ietf-ccamp-rsvp-restart-ext-05.txt actually had a section on
multiple node restart case and was rejected by the WG as addressing
multiple node restart case is NOT a goal (suffers from the law of
diminishing return). In other words the following statement in the ID-

  "[GR-EXT] also extends the Hello message to exchange information about
  the ability to support the RecoveryPath message.
  The examples and procedures in [GR-EXT] focus on the description of a
  single node restart when adjacent network nodes are operative.
  Although the procedures are equally applicable to multi-node restarts,
  no detailed explanation is provided."

is not accurate. Please see section 4 on the earlier version of the
[GR-EXT],
http://www.faqs.org/ftp/pub/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt
.

Thanks

Regards... Zafar



--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is
solely property of the sender's organization. This mail communication is
confidential. Recipients named above are obligated to maintain secrecy and
are not permitted to disclose the contents of this communication to
others.
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the originator of
the message. Any views expressed in this message are those of the
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.




--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.