Submission Date:
From:
To:
Cc:
Response Contact:
Technical Contact:
Purpose:
Deadline:
Liaisons referring to this one:
Referenced liaison:
Attachments:
Body:
2013-01-09
MPLS Working Group (Loa Andersson loa@pi.nu)
ITU-T SG 15 (Greg Jones greg.jones@itu.int)
ITU-T Study Group 15 (tsbsg15@itu.int)
Stephen Trowbridge (steve.trowbridge@alcatel-lucent.com)
Ghani Abbas (ghani.abbas@ericsson.com)
Adrian Farrel (adrian@olddog.co.uk)
Eliot Lear (elear@cisco.com)
Scott Mansfield (scott.mansfield@ericsson.com)
John Drake (jdrake@juniper.net)
Ross Callon (rcallon@juniper.net)
George Swallow (swallow@cisco.com)
Loa Andersson (loa@mail01.huawei.com)
MPLS Working Group (mpls@ietf.org)
Scott Mansfield (scott.mansfield@ericsson.com)
For information
LS 408 – E “Requirements and analysis of ring protection for MPLS-TP
networks”
(See below)
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-ringprotection.
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 MPLSTP 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