Re: Flooding using LMP extensions

[Roberto Albanese <albanese@coritel.it>]

Hi Richard, hi all,
i read your drafts and i' d like to make you some questions:

-  in section 5.3.1 is written that 
  "in order for the protection algorithm to abide by 
   the T-rec ms recovery requirement, it needs to be either:
    1. Aware of timing issues to be able to select 
       a proper path, or
    2. Passed a set of nodes and links that satisfy 
       the timing constraints.
 
   Due to the complexity of the first method, we believe 
   that the second method will be easier to develop and implement.  
   For example, a pruned topology may be considered for protection 
   path computation, where links/nodes that violate the strict 
   recovery time requirements are excluded."

   I see a problem in your example: since you consider 
   in each node a D queue max, you are taking account of 
   the worst-case. When the protection path travels more 
   than one node, you have the sum of these maximums.
   Using a pruned topology for protection path calculation
   you could be in a situation in which all the nodes/links 
   in the network are pruned.
   Instead i thouhgt that an algorithm considers a cost in
   each link/node (e.g. cost = D queue max + other delays...)
   could be better.
   This algorithm calculates the recovery paths and obtains 
   the best paths that minimize the total cost. 
   In this way we can ALWAYS obtain the best solution to
   the requirements of the protection paths. 

 -  in section 5.3.2 :

 Table 1. Required and Optional Data for Fault Notifications 
  -------------------------------------------------------------------- 
  Data Object    Fault   Fault Notify  Description 
                 Notify  Acknowledge 
  -------------------------------------------------------------------- 
  Message ID        R         R        Identifies notification messages 
  Fault Link ID     R         -        Identifies the failed link 
  Fault ID          R         -        Identifies sequence of failure 
  Channel Status    O         -        Indication of link fault status 
  Detecting Node ID O         -        Identifies the original node 
                                       that is reporting the failure 
  TTL               O         -        Time To Live field 
  -------------------------------------------------------------------- 
  R: required, O: optional, -: not applicable 

   couldn' t be a misunderstanding in the description of
   "Fault link ID"? 
   If it is used the "Channel Status " in the network too, 
   thinking to a starting scenario with no failures, there is
   in the LMP extended messages  the association 
   "Identifier of the failed link" with "Channel Status" = OK  
   even if there has been no failure in the network.
   If you agree with this, there could be a solution in making
   - "Channel Status" Required and not optional 
      (in example KO = failure, OK = good link);
   - "Fault Link ID" could become in example "Link ID".



- in Appendix A.2 when written that
  "The processing time D proc has been identified 
  in the literature [7] as a few tenths of a millisecond 
  in the case of an RSVP object.
  This value is smaller in the case of a simpler LMP message 
  requesting the activation of an LSP path."

  In the precedent period, did you consider the amount of processing
  delay coming the introduction of flooding extensions in LMP?
  I think that the implementation of this functionality in LMP 
  can add an important work in each node 
  (validation and checking of a message, timers, some of the 
  procedures  we can find, in example, in OSPF ).

Excuse me for misunderstandings.

Then i' m continuing to work on flooding fault 
notification using OSPF to be able to obtain
performance results on this, so we can compare them;
you know i agree with you in the good potentialities 
of  flooding fault notification.


Best regards.
Roberto

University of Rome - La Sapienza