Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

[Huub van Helvoort <[e-mail]>]

Hello Greg,

Please find in-line some more responses [Huub]
on behalf of the authors.

Note that I snipped agreed proposals.

Regards, Huub.

---8<---

The document is coherent, well written and proposes solution to practical scenario. But I’ve found that the document has certain overlap with draft-cui-mpls-tp-mfp-use-case-and-requirements at least in large parts of Section 2 of the draft-cheng-mpls-tp-shared-ring-protection-05. I believe it would bebeneficial if both groups of authors work together  to have single informational draft on requirements towards protection in MPLS-TP under multi-failure condition and have Ring and Interconnected Ring discussed as use cases, including requirements toward Ring Switch Protection protocol.
 
[Authors] Thanks a lot for your suggestion. Draft-cui described general requirements of Multi-failure protection, and Draft-cheng addressed some multi-failure scenarios. We will contact authors of draft-cui to see if we can work together with them on a requirements and use cases draft or we can contribute some text to draft-cui.

[Huub] draft-cui-mpls-tp-mfp-use-case-and-requirements describes use cases
for end-to-end linear protection only, although that is not specifically mentioned
in that draft. It is not applicable to ring protection.
The multiple failure condition in rings is related to link or node failures along the ring.

---8<---

·         Section 4.1.3 bullet 4 is hard to parse and once I’ve interpreted it cannot see it fit logically with other comments to Fig.4
 
[Authors] We will rephrase the section, and make it more clear.

[Huub] we are considering removing bullet 4, it is indeed confusing.

·         Section 4.2
o   I think that proposed protection mechanism uses link OAM and Continuity Check (CC) may be sufficient thus making Connectivity Verification unnecessary;
 
[Authors] Agree, we will change CC-V to CC.

[Huub] in RFC6371 the term CC-V is used. The CC and CV function are combined in the same
OAM packet that is used in pro-active mode.
The SF detected by the CC-V will trigger protection switch. ITU Document

---8<---

·         Section 4.3.1.2 discusses node failure scenario but, in fact, the scenario is not much different from link failure discussed already. I believe that the node failure scenario is most interesting to demonstrate behavior of protection mechanism and data flow when the egress (exit) node is the one that failed. Would wrapping prevent from forming infinite loop? Or wrapping without RSP protocol would create infinite loops? What about TTL handling?
 
[Authors]Agree, we will add some more text to make it more clear.

[Huub] note that wrapping is performed based on the source and destination node information
in the RPS packet and the information in the ring-map present in each ring node.
This will prevent infinite loop.

---8<---

·         Section 6. It may be beneficial to request IANA to create new registry RSP Request Code registry and allocate codes listed in the table on p.25. And define values not listed in the table as Reserved, e.g. 0b0010, 0b0100, 0b0111, etc.
[Authors]Agree, we will add it.

[Huub] we will use the same IANA request as was used for linear protection.
Section 5 of RFC6378. (for consistency).

-- 
*****************************************************************
              请记住，你是独一无二的，就像其他每一个人一样