Subject: [PWE3] PWE3 response to ITU-T SG15Q9 Liaison on TMPLS Ring Protection

From: Stewart Bryant <[email-masked]>
Date: Mon, 11 Feb 2008 11:17:37 +0000

To:
[email-masked]
[email-masked]

CC:
[email-masked]
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>

[email-masked] <mailto:[email-masked]>
[email-masked]
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>
[email-masked] <mailto:[email-masked]>

[email-masked]

To SG15 Q9 For comment

Thank you for your liaison on TMPLS Ring Protection

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

The mechanism proposed in this document is 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.

This is a new specialist repair mechanism proposed for
a specialist topology. It is clear that the problem could also
be solved by the widely deployed repair mechanism based on
nested MPLS encapsulation  (so called MPLS-TE fast reroute). 
Please could you point us to information  explaining the
reasons why this additional mechanism is required.

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 concerned that unlike existing MPLS fast re-route
mechanisms it appears that 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.

In  Section 7 Para 5 the document says:

"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 hierarchy in order to set the hold-off timer correctly
and what impact this has on the 50ms requirement?

In Section 7 para 8 the document says:
 
"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
end to end - including any backtracking needed for repair is 255.

In Section 18 Label assignment the document says
 
"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 label values  may
be independently assigned using local policy in the ring
nodes.

Regards

Stewart Bryant
IETF PWE3 WG Co-chair
_______________________________________________
pwe3 mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pwe3