[mpls] MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01

Mach Chen <mach.chen@huawei.com> Fri, 23 August 2013 08:09 UTC

Return-Path: <mach.chen@huawei.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFF11E815E for <mpls@ietfa.amsl.com>; Fri, 23 Aug 2013 01:09:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAtgDFG6BTlW for <mpls@ietfa.amsl.com>; Fri, 23 Aug 2013 01:08:57 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4F87511E8173 for <mpls@ietf.org>; Fri, 23 Aug 2013 01:08:56 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWI97379; Fri, 23 Aug 2013 08:08:52 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 23 Aug 2013 09:08:14 +0100
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 23 Aug 2013 09:08:47 +0100
Received: from szxeml558-mbs.china.huawei.com ([169.254.8.128]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 23 Aug 2013 16:08:41 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "loa@pi.nu" <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "draft-rhd-mpls-tp-psc-priority@tools.ietf.org" <draft-rhd-mpls-tp-psc-priority@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, "martin.vigoureux@alcatel-lucent.com" <martin.vigoureux@alcatel-lucent.com>
Thread-Topic: MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01
Thread-Index: Ac6f1/oEfbWhKMZFQICpbkCZc3Y4HQ==
Date: Fri, 23 Aug 2013 08:08:41 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE255C02949@szxeml558-mbs.china.huawei.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.96.176]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [mpls] MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Aug 2013 08:09:02 -0000

Hi,

I have done my MPLS-RT review on draft-rhd-mpls-tp-psc-priority-01.

The draft proposes three changes to RFC6378

1) swap the priority of FS and SF-P: the scenario is valid and this solution to that scenarios is also valid. At the same time, need to consider whether this change will lead to other potential problems. With this change, the operator will not be able to forth switch the traffic to protection path when signal fail in protection path. This may required in the situation where both working and protection path are failed, and the operator may hope to forth switch the traffic to the protection path before making sure the working path is recovered, or before determining what caused the working path failed. 

2) raise the priority of "Clear SF": the situation described in Appendix B may occur if the "Clear SF" input is really ignored and dropped after reporting to the PSC logic. IMHO, the critical inputs (like SF, Clear SF) should never be ignored and dropped, but they could be suspended and processed later on. Raise the priority is a potential valid solution to the issue.  In addition, the current Fpath only has two states, 0 and 1, it cannot convey the situation that both protection and working path are failed. If there is third state, for example, 2 that indicates the anomaly condition is on both protection and working path, thing may be different.

3) Freeze command, I think it is a valid solution if the priority of FS and SF-P is swapped. One clarify question about it, does it mean that both ends need to configure the Freeze command?

The format of this draft is similar to draft-cdh-mpls-tp-psc-non-revertive-00, the proposed updates look like erratas. So, I do believe the better way is to do a bis IMHO.


Best regards,
Mach