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

["Hejia (Jia)" <[e-mail]>]

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