Skip to main content

Liaison statement
In response to "Recommendation ITU-T G.8131/Y.1382 revision – Linear protection switching for MPLS-TP networks"

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2013-01-08
From Group mpls
From Contact Loa Andersson
To Groups ITU-T-SG-15-Q10, ITU-T-SG-15-Q12, ITU-T-SG-15-Q14, ITU-T-SG-15-Q9
To Contacts greg.jones@itu.int
Cc stbryant@cisco.com
adrian@olddog.co.uk
mpls@ietf.org
jdrake@juniper.net
Scott.Mansfield@Ericsson.com
lear@cisco.com
yoichi.maeda@ttc.or.jp
steve.trowbridge@alcatel-lucent.com
Ghani.Abbas@ericsson.com
tsbsg15@itu.int
hiroshi.ota@itu.int
loa.andersson@ericsson.com
rcallon@juniper.net
swallow@cisco.com
Response Contact loa@pi.nu
rcallon@juniper.net
swallow@cisco.com
Technical Contact loa@pi.nu
Purpose In response
Attachments (None)
Liaisons referred by this one Recommendation ITU-T G.8131/Y.1382 revision – Linear protection switching for MPLS-TP networks
Body
Thank you for your liaison statement COM15-LS435-E "Recommendation
ITU-T G.8131/Y.1382 revision - Linear protection switching for
MPLS-TP networks" with the questions and concerns that it raises
about RFC 6378 MPLS-TP linear protection.

We have passed your concerns to the working group. We hope that
anyone who agrees with them and is concerned to modify the
MPLS-TP linear protection specification will write an Internet-Draft
using the normal IETF process. We know that a number of people have
been actively discussing the issues you raised with a view to making
modifications to the specification presented in RFC 6378.

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

#1 RFC5654 includes R.83, which states "The external controls as
defined in [RFC4427] MUST be supported."  RFC4427 clearly requires
FS > SF-P; please see the LS from the IETF to the ITU dated 2012-08-06.
An alternate approach allowing SF-P > FS could be defined such that
it can co-exist with FS > SF-P.

#2 The scenario described in Annex 2 of your liaison describes a defect
in RFC 6378. It makes no sense to continue to send SF(1,1) when W has
not failed.

#3 No requirement for EXER was documented in RFC5654. There is also
no mention of EXER in RFCs 4427 an 6372. EXER could be added to the
MPLS-TP function-set.

#4 There is currently no definition of SD for an MPLS environment.
SD is included in RFC6378 as a placeholder (see RFC6378
Section 3.1: "The determination and actions for SD are for
further study and may appear in a separate document"). We encourage
interested parties to submit an Internet-Draft for consideration by
the IPPM and MPLS working groups.
There is no requirement MS-W in RFC5654 or RFC4427.  We encourage
interested parties to submit an Internet-Draft for consideration
by the MPLS working group.

#5 You ask whether your understanding that Clear Signal Fail (SFc)
is used to trigger the WTR in section 4.3.3.5 of RFC 6378. CSF should
not be thought of as a trigger, but as the removal of a trigger.  If
a node has multiple alarms active, the removal (Clear) of the highest
priority alarm causes a node to re-evaluate its current inputs and
act accordingly.  If a SF is Cleared and there are no other active
inputs, the resulting transition into Normal will trigger WTR, per
rfc6378 sec. 3.5.

#6 RFC6378 is a protocol specification and does not describe how to
implement error reporting to the operator. An error reporting paradigm
 could be defined.

#7 Mechanisms for alerting operators about mismatches are outside
of the scope of the protocol specification: they may be considered
as issues for implementers. A default operational state for MPLS-TP
linear protection in absence of any specific configuration could
be defined.

#8 The scenario described in Annex 3 of your liaison should be
addressed in an Internet-Draft describing the problem and proposing
a solution.

#9 RFC5654 R.83 requires that the external commands in RFC4427 be implemented.
RFC4427 defines 'Freeze' as "A configuration action that prevents any
switch-over action from being taken".  This is a local behavior on a node (there
is no signaled message as a result) and thus it is not part of the MPLS-TP
linear protection protocol specification.
RFC4427 defines "Manual switch-over for recovery LSP/span" as "A switch-over
action, initiated externally, that switches normal traffic to the working
LSP/span, unless a fault condition exists on the working LSP/span or an equal or
higher priority switch-over command is in effect".  We equate this function to
MS-W and agree that it is missing from RFC6378.  If there is a desire for
support of this additional command it should be documented along with protocol
extensions in an Internet-Draft for consideration by the MPLS working group.

Loa Andersson
Ross Callon
George Swallow
mpls working group chairs