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

From: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Apr 2015 22:49:10 +0000

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

---

From: "Hejia (Jia)" <[email-masked]>
Date: Thu, 30 Apr 2015 18:48:30 +0000

Hi All,

I have finished reviewing draft-cui-mpls-tp-mfp-use-case-and-requirements as the member of MPLS Review team and have the following comments:

* Is the document coherent?

Yes. It describes the rational to complement current MPLS-TP linear protection mechanisms with m:n protection scheme.

* Is it useful (i.e., is it likely to be actually useful in operational networks), and is the document technically sound?

Yes, but it is useful in specific scenarios as indicated by the draft, not all cases. And it may cost much more resources than usual 1+1/1:1 protection, depending on the value m for example in case of m:1 protection. Therefore, it is better to point out as well in the draft the resource cost for m:1 and m:n protection for deployment consideration.

* Is the document ready to be considered for WG adoption?

Yes. But I have the following comments which appreciate consideration when further developing this document.

1)    Broadcast bridge:

The description of broadcast bridge in Section 3

“At the Node A and in the absence of faults, traffic is transported over its respective working entity and may be simultaneously transported over one of its protection entities (in case of a broadcast bridge),….”

However, in both ITU-T G.870 and IETF RFC4427, only in the event of protection switching (e.g. in case of fault on the working entity) the normal traffic signal is additionally connected to the protection transport entity in case of a broadcast bridge. Therefore, it is suggested to adjust the description in this paragraph to follow the definition in RFC4427 and ITU G.870 about broadcast bridge.

2)    Resource cost for m:1 and m:n protection

As indicated above, it is suggested to add consideration for resource cost of m:1 and m:n protection in Section 4.1 and Section 4.2 respectively.

3)    “Must” or “May(optional)”?
Section 5 uses “Must” to describe the requirements of MPLS-TP m:1 and m:n. I’m wondering if it is more reasonable to use “May (optional)” since it is more typical in some special use cases.

B.R.

Jia