|
Thanks for reading the document and extensive feedback. Please see my comments inline.
> -----Original Message----- > > 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 agree with the analysis. The first problem becomes similar to problems of finding QoS routes, which are usually NP-hard. You can apply some heuristics to find polynomial-time algorithms but the second method is cleaner. We prefer it as well. > 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. I’m sorry about the confusion. My intention was exactly what you mentioned. I will rephrase the paragraph in the next iteration. I definitely don’t want to include an algorithm in the draft and impose it on anybody, but will indicate more information about possible solutions. I think at this point, the draft is pretty general to accommodate any solution, barring the misunderstanding that you mentioned. > - 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". I’m not sure I understand you correctly. Let me explain a bit what we currently have.In the draft, the pair “Fault ID” + “Fault Link ID” uniquely identifies the failure and therefore makes sure that you don’t process duplicated “fault Notify” messages.We were using “Channel Status” to identify Loss of Light, Signal Degrade, etc. If people adopt the LMP idea, we were also going to support “Channel Status” OK for reversion, as an optional step. Since this is a non time-sensitive issue, signaling the ingress to revert to the old working path can also be applied.w/r to “fault link id” and “link id”, I will check again the other drafts and send you an answer on this particular point. > - 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 ). From our experience, we didn’t have to add timers. The LMP security implementation does add some overhead. But from our testbed experience, LMP messages were processed pretty fast. What this appendix points to is the fact that one doesn’t need to think that recovery of GMPLS networks cannot be done within small time bounds. > 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; Great. We will be able to compare methods once you have running code. > you know i agree with you in the good potentialities > of flooding fault notification. Thanks. > Best regards.> Roberto> > University of Rome - La Sapienza
Richard. |