[mpls] ITU-T LS on MRPS (RFC 8227)

Italo Busi <Italo.Busi@huawei.com> Tue, 11 June 2019 16:41 UTC

Return-Path: <Italo.Busi@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 254C8120199 for <mpls@ietfa.amsl.com>; Tue, 11 Jun 2019 09:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1i8GMvisZO2 for <mpls@ietfa.amsl.com>; Tue, 11 Jun 2019 09:41:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2069E120019 for <mpls@ietf.org>; Tue, 11 Jun 2019 09:41:32 -0700 (PDT)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id D50224C6401A28C6B07D for <mpls@ietf.org>; Tue, 11 Jun 2019 17:41:29 +0100 (IST)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by lhreml706-cah.china.huawei.com ([10.201.108.47]) with mapi id 14.03.0415.000; Tue, 11 Jun 2019 17:41:27 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: ITU-T LS on MRPS (RFC 8227)
Thread-Index: AdUgdB9l/kr7N5AHQRmUWXnjfygE4A==
Date: Tue, 11 Jun 2019 16:41:27 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B2775D083@lhreml504-mbs>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.126]
Content-Type: multipart/related; boundary="_004_91E3A1BD737FDF4FA14118387FF6766B2775D083lhreml504mbs_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/cvYW1n8PU6owPZfTz2ssums3MJY>
Subject: [mpls] ITU-T LS on MRPS (RFC 8227)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 11 Jun 2019 16:41:35 -0000

MPLS WG,

I have read the ITU-T LS 1609 (https://datatracker.ietf.org/liaison/1609/)

I think that the technical issue described in the LS is valid

However, the definition of short and long path in RFC 8227 is independent from the location of the unidirectional failure:

   Here, the short path refers to the shorter path on the ring between
   the source and destination node of the RPS request, and the long path
   refers to the longer path on the ring between the source and
   destination node of the RPS request.  Upon receipt of the RPS request

It seems to me that the MRPS protocol, as defined in RFC 8227, would still work if both nodes A and B consider the span affected by the unidirectional failure as the long path:


   The destination node MUST acknowledge the received RPS

   requests by replying with an RPS request with the RR code on the

   short path and an RPS request with the received RPS request code on

   the long path.  Accordingly, when the node that detects the failure

   receives the RPS request with RR code on the short path, then the RPS

   request received from the same node along the long path SHOULD be

   ignored.

In this case node A will receive RR from the long path (which has no failures) and ignore the SF which is not received from the short path (because of the unidirectional failure).

Therefore, it seems that the RPS protocol defined in RFC 8227 could work also with two‑nodes ring, assuming that both nodes have a common view about which span is the short path and which is the long path

The confusion is due to the fact that in a two‑nodes ring, the two paths have the same topology distance so the definition of short and long path is “arbitrary” and the required behavior seems not described in RFC 8227

It seems therefore possible to conclude that the RPS protocol defined in RFC 8227 could work also with two‑nodes ring but the description of the behavior is missing from RFC 8227

What do you think?

Thanks, Italo

Italo Busi
Principal Optical Transport Network Research Engineer
Huawei Technologies Co., Ltd.
Tel : +39 345 4721946
Email : italo.busi@huawei.com
[cid:image001.png@01D52085.435809C0]

This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!