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

["Adrian Farrel" <[e-mail]>]

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: <[e-mail]>
To: "Olufemi Komolafe" <[e-mail]>
Cc: "ccamp" <[e-mail]>; <[e-mail]>; <[e-mail]>; 
<[e-mail]>
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:   [phone]
> Mail:  [e-mail]
> .............................................
>
>
>
>
>
> "Olufemi Komolafe" <[e-mail]>
> 发件人： [e-mail]
>
> 2006-09-19 20:45
>
>        收件人：        <[e-mail]>, <[e-mail]>
>        抄送：  "ccamp" <[e-mail]>
>        主题：  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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Zafar Ali (zali)
> Sent: 10 July 2006 04:04
> To: [e-mail]; [e-mail]
> 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.
>