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

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



hi dan 

yes i have a very practical issue - the document would then deal with 
remedial to remedial - ... but do we have any feedback on initial 
remedials ?

thanks,
- d. 





Dan Li <danli@huawei.com>
Sent by: owner-ccamp@ops.ietf.org
25/09/2006 09:27
 
        To:     Olufemi Komolafe <femi@dcs.gla.ac.uk>, gjhhit@huawei.com
        cc:     ccamp <ccamp@ops.ietf.org>
        Subject:        Re: Comments on 
draft-li-ccamp-multinodes-gr-proc-00.txt,


Hi Femi,

Thanks for your valuable suggestion! 

The intention for this draft is clarify the procedures for multi-nodes 
restart, so five typical scenarios have been listed in the draft, I think 
most of the failed cases are covered by these five scenarios. As you have 
pointed out, these scenarios may be raised due to multiple nodes fail, or 
a subsequent control channel failure. Yes, you're right! It may be more 
generic to classify these scenarios, such as: "What should happen if a 
restarting node fails to get a RecoveryPath/Path message from its 
downstream/upstream neighbor?", but I think it may be more clear to 
address the specific cases in the draft at least during the initial stage.

Any comments are very welcome!

Best regards,

Dan



 
----- Original Message ----- 
From: Olufemi Komolafe 
To: danli@huawei.com ; gjhhit@huawei.com 
Cc: ccamp 
Sent: Tuesday, September 19, 2006 8:45 PM
Subject: 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