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

State Posted
Posted Date 2013-05-15
From Group mpls
From Contact Loa Andersson
To Group ITU-T-SG-15
To Contacts tsbsg6@itu.int
Ccstbryant@cisco.com
adrian@olddog.co.uk
mpls@ietf.org
pwe3@ietf.org
ccam@ietf.org
Scott.Mansfield@Ericsson.com
db3546@att.com
jdrake@juniper.net
Steve.Trowbridge@alcatel-lucent.com
Ghani.Abbas@Ericsson.com
malcolm.betts@zte.com.cn
koike.yoshinori@lab.ntt.co.jp
huubatwork@gmail.com
Kam.Lam@alcatel-lucent.com
hiroshi.ota@itu.int
tsbsg15@itu.int
Response Contact loa@mail01.huawei.com
Technical Contact eosborne@cisco.com
Purpose In response
Attachments (None)
Liaisons referred by this one Recommendation ITU-T G.8131 revision – Linear protection switching for MPLS-TP networks
Body
In respons to "Recommendation ITU-T G.8131 revision – Linear protection
switching for MPLS-TP networks"
===================================================================================

Thank you for your liaison statement COM15-LS435-E "Recommendation
ITU-T G.8131 revision - Linear protection switching for MPLS-TP
networks" with the questions and concerns raised about RFC 6378
MPLS-TP linear protection.

We appreciate the number of people who have actively contributed
to this work and encourage anyone interested to participate in the
on-going discussion on the MPLS mailing list.

Please find comments on some of the points raised in your liaison:

Point 1 (Issue of the priority of FS and SF-P):
-----------------------------------------------
PSC is built to satisfy the requirements found in RFC 5654 which
points to RFC 4427.  An analysis and interpretation of the
requirements is found in a liaison called “Reply to ITU Liaison
Statement regarding MPLS-TP Linear Protection

(https://datatracker.ietf.org/liaison/1174/).
RFC 5654 and RFC 6372 were liaised to the ITU-T during their
development and this issue was not raised at that time. Changes to
the requirements must be made using the normal IETF process.

Standardization is an iterative process, and changes to standards
should be made in a backward compatible way.  There is an individual
Internet Draft that has been submitted and is being discussed on the
mailing list as per the IETF process.

Point 1.c: (Discrepancy between the RFC and G.808.1 concerning the
           description of “Forced switch-over for normal traffic”)
------------------------------------------------------------------
A solution has been submitted to the working group that addresses
point 1.c.  Please discuss on the mailing list as per the IETF process.

Point 3 (Exercise Command):
---------------------------
There are individual drafts addressing this point and discussion is
on-going on the MPLS mailing list.

Point 4 (Signal Degrade):
-------------------------
SD is already included in the alarm hierarchy as defined by RFC 6378.
There is an individual Internet Draft that currently addresses the
changes to the state machine and discussions on SD and its definition
are progressing on the MPLS list per the IETF process.

Points 7 (Provisioning Mismatch), 8 (Reversion corner-case):
------------------------------------------------------------
There is an individual Internet draft that has been submitted and is
being discussed on the mailing list as per the IETF process.

Point 9 (“Manual switch-over for recovery LSP/span" and "Freeze"):
------------------------------------------------------------------
Regarding “Manual switch-over for recovery LSP/span”, if an
implementation behaves in the way described in Point 9, then that
behavior should be considered a bug.  If the protection path is
available, it can be used.  The document is not an implementation
guide, it is a protocol specification.

To support the Freeze functionality, an individual Internet draft has
been submitted and it is being discussed on the MPLS mailing list.

Loa Andersson
Ross Callon
George Swallow
MPLS Working Group co-Chairs