Re: I-D ACTION:draft-soumiya-lmp-fault-notification-ext-01.txt

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Two brief questions about this draft...

1. In section 3 you say

   [Optional]: If the receiving node has activated one or more recovery 
   paths, it sends a RecoveryCompleteNotify message to either the egress 
   nodes of the recovery LSPs or to the NMS.  It continues sending 
   RecoveryCompleteNotify messages periodically until it receives a 
   RecoveryCompleteNotifyAck message or a timer to retry sending 
   expires. 

   ...Isn't this a change to the way LMP operates? That is, before this
   message, LMP is a neighbor-to-neighbor protocol.

2. Fault repair

  I don't see anything in your draft that discusses fault repair. How
  does the reporting node revoke its fault report?

  This would appear to be a requirement otherwise repaired 
  resources will never be made available again. I think that when 
  you add this function and add the necessary controls to ensure 
  that each node has the right state (fault or no fault) you will have
  invented a link state protocol.

  At this point I don't see what LMP gives you that an existing
  link-state protocol doesn't already deliver. Certainly the 
  speed of reporting of faults to every node in the network 
  will be lost once you have to prevent "thrash" of fault and 
  fault clear notifications. In any case, it is not clear to me that
  every node in the network needs rapid notification of faults -
  only those nodes that constitute repair points for the LSPs 
  that used the failed resource need to know quickly and they 
  hear about the problem through a directed Notify message
  that must propagate faster than any hop-by-hop protocol
  can.

Adrian