Liaison Statement: in Response to COM 15 LS 408 E Requirements and Analysis of Ring Protection

Liaison statement: In response to COM 15 – LS 408 – E “Requirements and analysis of ring protection for MPLS-TP networks”

Thank you for your liaison statement COM15-LS408-E "Requirements and analysis of ring protection for MPLS-TP networks", with the questions and concerns that it raises about draft-ietf-mpls-tp-ring-protection.

We have passed your concerns to the working group. These issues are being discussed by the MPLS WG and the authors of draft-ietf-mpls-tp-ring-protection and we invite interested individuals to participate in these discussions using the normal IETF process.

Here are some additional notes to the specific points in your liaison.

To avoid confusion we have numbered the suggested requirements in your Liaison as LR1, LR2, etc. (“LR” for Liaised Requirement”) and we refer to the requirements in RFC 5654 using the notation as published (i.e., R96, R97, etc.).

The first request in the liaison statement is to provide status of individual/working group drafts containing MPLS-TP ring protection solutions. draft-ietf-mpls-tp-ring-protection describes the applicability of the generic linear protection mechanisms (RFC 6378) to ring topologies. As such it sets a baseline for determining the optimization value of any other proposed solutions. This draft also discusses a number of the different mechanisms that can be used in ring protection and highlights the optimizations that can be made in packet networks as compared to traditional transport networks where tunnelling is not so readily available. The status of this MPLS working group draft is ”work in progress”. There are also a number of individual drafts proposing different solutions and addressing different aspects of ring protection. The chairs hope that these documents will be discussed further on the MPLS mailing list so that it becomes clear which offer the best solutions addressing all the requirements and providing optimization benefits. The chairs also hope that the authors of the various drafts will attempt to find compromise positions that allow their approaches to be merged. Lastly, the chairs hope to hear of intent to implement that will clearly show which drafts have concrete support.

The first requirement for G.8132 is unnumbered, and is the sole sentence in the section ‘Requirements for ITU-T G.8132’. We agree that the requirements and optimization criteria for ring protection set out in RFC 5654 should be taken into account. In particular, we draw your attention to the preamble in Section 2.5.6.1 and the statements made about the cost/benefit implications of specialized protection solutions.

LR1 simply updates RFC5654 R96 to allow it to apply to protection methods other than 1:1 and 1+1. The text as written does not preclude applying the same requirement to other protection mechanisms, but if a change is necessary it should be proposed in the MPLS WG using the normal IETF process.

LR2 and LR3 add ring-specific requirements to RFC5654. As with LR1, any new requirements for MPLS-TP should be proposed in the MPLS WG as per normal IETF process.

For the technical analysis, we invite the discussion of these scenarios on the MPLS WG email list.

T1 presents a scenario where linear protection would not suffice in the face of multiple failures. The given scenario is only one possible deployment model. There are others where linear protection would suffice. One such model is the wrapping protection as defined in draft-ietf-mpls-tp-ring-protection, and another is treating the aggregation and access networks as separate protection domains.

T2 paraphrases section 2.5.6.1 of RFC5654 as “MPLS-TP ring protection should be optimized for simplification of the ring operation and the resources consumption around the ring”. The use of ‘should’ implies some sort of normative requirement for ring-specific optimization. However, section 2.5.6.1 and R96-R109 do not contain any such normative requirement. RFC5654 allows for optimizations “such that the performance of those mechanisms within the topology is significantly better than the performance of the generic mechanisms in the same topology” while weighing the benefits of ring-specific mechanisms “against the costs of developing, implementing, deploying, and operating the additional optimized mechanisms”. The existing linear protection mechanisms can be used in any topology, including a ring. The MPLS WG believes that the reuse of linear protection mechanisms in a ring topology (i.e. draft-ietf-mpls-tp-ring-protection) will meet the performance targets expressed in RFC5654 in a ring topology, and will do so while allowing the operator to deploy a single protection method across all possible network topologies.

Additionally, the increasing sophistication of ring networks over time (singly or multi-interconnected rings, subtended rings, transport paths that cross multiple rings, etc.) makes it difficult to distinguish a ring network from a mesh network. Any definition of ring-specific protection would need to contain clear definitions about what does and does not constitute a ring network.

Annex 2 refers to C-2098. C-2098 has not been made available for IETF review so we are unable to comment definitively. Some people who have read the document have reported that C-2098 requires a dynamic protocol that uses downstream-assigned labels in order to provide a mechanism that is essentially identical to the IETF's MPLS Fast ReRoute. The MPLS WG recommends the ITU consider adopting RFC3209 and RFC4090 as the basis for any MSRP work.

For the IETF MPLS WG

Loa Andersson

Ross Callon

George Swallow