[mpls] MPLS-RT: review draft-cui-mpls-tp-mfp-use-case-and-requirements

[Gregory Mirsky <[e-mail]>]

Dear Authors, et. al,
I was tasked to review the draft-cui-mpls-tp-mfp-use-case-and-requirements according the guidance:

Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?  We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).

The document is coherent and well written. It does provide clear requirements toward M:N protection mechanism. But I have concerns:

*         There's no discussion, nor formal definition of what constitutes simultaneous detection of multiple failures. Is that particular time interval, e.g. 10 msec, or relative to a failure detection interval?

*         Discussion of use cases does not demonstrate that there is sufficient number of scenarios where M:N protection is required. Thus I could not conclude that standardization of a solution that would comply with formulated in the document requirements is needed.
Please find more comments to the document below:

*         I found that the document that presents use cases of multi-failure protection and formulates requirements toward possible solution is on Standard track. I think that such document is more appropriate to be on Informational track;

*         Abstract:

o   I believe that references in the Abstract are not suggested and rewording of the first paragraph encouraged.

*         Introduction

o   s/MUST SHOULD/MUST/ - req. 65 and 67 in RFC 5654 use MUST for 1:1 and 1:n protection schemes

*         Document Scope

o   After reference to existing GMPLS-based restoration mechanisms not clear whether scope of the document is on protection or restoration mechanisms. Networks that do not use distributed control plane do use centralized management system. Such management system can provide service restoration in case of cascading failures as pointed in Section 4.1.2. If that is the case, should the document be discussion service resiliency in case of multiple failures?

Regards,
                Greg