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 |