[mpls] proposed drafts for aligning MPLS-TP PSC linear protection protocol to transport requirements

[D'Alessandro Alessandro Gerardo <[e-mail]>]

Dear all,
we would like socializing the herebelow drafts that were submitted some months ago with the aim to align PSC protocol (RFC 6378) to ITU-T transport requirements. I would appreciate your comments about the proposed mechanisms and behaviours.

draft-rhd-mpls-tp-psc-priority-00
draft-cdh-mpls-tp-psc-non-revertive-00
draft-rhd-mpls-tp-psc-sd-00
draft-dj-mpls-tp-exer-psc-01 / draft-osborne-mpls-psc-alive-00

The above drafts cover most of items highlighted in ITU-T liaisons about PSC and they propose solutions in line with MPLS-TP transport requirements.
A list of main liaisons exchanged between ITU-T and IETF with the aim to align PSC behavious with ITU-T transport requirements for linear protection are given below:
https://datatracker.ietf.org/liaison/1162/  (June 2012)
https://datatracker.ietf.org/liaison/1205/<https://datatracker.ietf.org/liaison/1162/>  (October 2012)
https://datatracker.ietf.org/liaison/1229/<https://datatracker.ietf.org/liaison/1162/>   (January 2013)
https://datatracker.ietf.org/liaison/1234/<https://datatracker.ietf.org/liaison/1162/>   (February 2013)
https://datatracker.ietf.org/liaison/1256/<https://datatracker.ietf.org/liaison/1162/>   (May 2013)

Some details abou the proposed drafts for align PSC behaviour with transport requirements:

draft-rhd-mpls-tp-psc-priority-00 proposes swapping the priorities between FS and SF-P (see section 4.3.2 of rfc6378).
Among the others, behaviors that will be fixed with the proposed update are:
Use case A) At first, working path(WP) and protection path(PP) are normal. Then, Forced Switch(FS) command is issued for maintenance on the WP and the traffic moves from WP to PP.  When Signal Fail occurs on PP, service cannot recover and is interrupted. This could occur for example as a result of accidentally un-plugging a PP fiber.
Use case B) If there is an existing signal fail on a protection path (SF-P),and FS command is issued by accident  the traffic on WP will move to PP. This results in an interruption of service from which you will not automatically recover, because PSC should not have switched the traffic from WP to PP.
Discussion about this draft led to the proposal to modify RFC 4427 that was "written correctly though lacking in detail causing mis-interpretation" that led to the current PSC set of priority that the above draft is proposing to modified and to align to the required transport behavior. draft-helvoort-ccamp-fs-priority-00 has been submitted to CCAMP for clarifying the definitions related to Manual Switch and Forced Switch and their usage relative to priorities.
The way this behavior has to be incorporated into the PSC has to be discussed. The text proposes to replace the current behavior with the new one. If there is consensus to procede in that way this can bring to a simple and effective way to operate the protocol.

----------------------------------------------------------------------
draft-cdh-mpls-tp-psc-non-revertive-00 contains the updates to RFC6378  to change non-revertive operations to behaves in the same way irrespectively of the trigger of protection switching (fault or operator command FS, MS).  Consequently an operator command, Manual Switch to Working (MS-W) a.k.a “Manual switch-over for recovery LSP/span” is also added to enable this behavior. From an operational point of view, MS to working path has also to be supported to be able to initially align at both sides in case of non-revertive switching mode. MS to working path is defined in RFC 5654, requirement 83.

The proposed MS-W command is of equal priority to the existing MS-P command, and there is text to handle the simultaneous or sequential occurrence of two equal-priority commands. This behavior, already adopted in other transport network protection switching protocol, can be used for other addition to the protocol in the future.

----------------------------------------------------------------------
draft-rhd-mpls-tp-psc-sd-00  provides extensions to the PSC state machine to handle Signal Degrade (SD).  It does not define SD or provide scope around where or how SD may be used similarly as it already happen in the draft in handling other defects like SF (Signal Failure).
In MPLS-TP survivability framework  [RFC6372], a fault condition includes both Signal Fail (SF) and  Signal Degrade (SD) that can be used to trigger protection switching.
While the standardization lack of an SD definition and detection mechanisms, the relevant behaviors in terms of protection actions may already be defined.

----------------------------------------------------------------------
draft-dj-mpls-tp-exer-psc-01 proposes adding the EXER/RR commands to test if the APS communication is operating correctly. In other words both APS process logic including state machine and APS channel on protection path, without service disruption and without affecting any protection operation, unless the protection transport entity is in use. This command is documented in R84 of [RFC5654] and it is part of ITU-T transport requirements.
An alternative proposal is documented in the Appendix B of RFC6378 that utilizes the Lockout of Protection (LO) or Forced Switch (FS) in combination of OAM functionalities. However, it has some functional limitation and has a potential risk of losing traffic as a signal failure might occur during the exercise operation. In that case, LO or FS has to be canceled to allow the PSC protocol to provide proper switching.
A further alternative proposal is documented in draft-osborne-mpls-psc-alive-00 that anyway show some functional limitations because cannot validate the PSC state machine status and probably the Local Request logic.


The authors encourage the IETF experts to comment on these drafts, eventually proposing other options/mechanisms that can satisfy the same requirements.
Best regards,
Alessandro, Huub, Jeong-dong, Taeksid
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

[cid:[e-mail]]Rispetta l'ambiente. Non stampare questa mail se non è necessario.