Subject: Liaison from ITU-T Q9/15 on T-MPLS ring protection.

From: Stewart Bryant <[email-masked]>
Date: Mon, 07 Jan 2008 17:50:09 +0000

We received a liasion from ITU-T Q9/15 on T-MPLS ring protection.

https://datatracker.ietf.org/liaison/386/

Please can I have your views by 22  January so that we can respond to 
the liaison.

Thanks

Stewart

My thoughts are as follows:

This is clearly a new type of MPLS packet forwarding technology and
as such comes under the purview of the MPLS Change Process (RFC 4929).
It should therefore be pursued through the IETF Standards Process.

It is regrettable that a new, specialist repair mechanism is
proposed for this topology, when it is clear that the problem could be 
solved by the
widely deployed repair mechanism based on nested MPLS encapsulation
(so called MPLS-TE fast reroute).

It is our understanding that ring protection requires signaling between the
two sides of the failure before the repair can start and that this would 
seem
to be therefore slower than the already deployed  mechanism that allows
the repairing system to autonomously invoke the repair.

We are further concerned that unlike existing MPLS fast re-route mechanisms
it is not possible to test the repair path without causing disruption to 
the
operation of the ring.

We are concerned that this mechanism will require two labels for every
T-MPLS path through the network and hence does not scale as well
as an encapsulation based protection.

Then I have some detailed comments:

In  Section 7 Para 5 you say:

 Hold-off time: to avoid protection switching cascade in different 
network layers when a
lower layer network protection mechanism is activated in conjunction 
with the T-MPLS
layer protection scheme. Usage of hold-off timers allows the lower layer 
to restore working
traffic before the T-MPLS layer initiates a protection action.

Please could you explain how a ring "knows" its current level in the 
heirarchy in order
to set the hold-off timer correctly and what impact this has on the 50ms 
requirement?

In Section 7 para 8 you say:
a) The switching protocol shall be able to accommodate as a minimum up 
to 127 nodes on
a ring.

It might be better to express this in terms of a reminder that the 
maximum number of hops
that a T-MPLS packet can traverse - including any backtracking needed 
for repair
is 255.

In Section 18 Label assignment you say
In the T-MPLS Shared Protection Ring no restrictions are applied to the 
labels allocation along the
normal and protection connections (besides T-MPLS per platform and per 
interface label space
requirements as described in appendix III/G.8110.1). However, at every 
node there must be a
deterministic relation between the labels assigned for normal and 
protection connection in both
West and East directions.

Please confirm that you mean that it must be possible to associate the 
normal protection
labels, but that the labels may be independently assigned using local 
policy in the ring
nodes.

<end>