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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 11 June 2019 18:26 UTC

Return-Path: <Alexander.Vainshtein@ecitele.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 AE91A1200A3 for <mpls@ietfa.amsl.com>; Tue, 11 Jun 2019 11:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com
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 20spayDVZ05G for <mpls@ietfa.amsl.com>; Tue, 11 Jun 2019 11:26:56 -0700 (PDT)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (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 9B453120074 for <mpls@ietf.org>; Tue, 11 Jun 2019 11:26:55 -0700 (PDT)
Received: from [46.226.52.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id 32/C6-04913-C62FFFC5; Tue, 11 Jun 2019 18:26:52 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA2VTbUxTZxjlvR/lQqi5FBiPVcjslKHYjhIZELf MZS6SEdhYWEyGBC9QuSWldP2YYLbFLbANGK6DLtECorSMD9kwKqJjMigfAioMh1vmRCTANqhg 0WQKBNy9vcW57M+Tc8857/Oc5817KVzS6i2lVPlGlV7LaGQiX2LHhnP5cs39x/siP7Wuj11xt ZOxN+sayV1YfGHPHBlvty9ib2HvkmptRl7+fpI9ZWskdZdOE/ndy8voMJpvIEqQD0XQ3+LQ1f pKCfKlJLQZg6K710TCxziC0fs1bpeIfhnOnBoT8TiQDoNJi43kMU5vgYrey5yHogLocGi6kcj DQHorOFwJgjsKhi3nEU8TnLuvxZ+nxXQaOL+04TyW0LvhdvcVd3Mf+nW4U97nxoh+Bh4ONmPC oGC4OVXjxkAHwsSI4Ac6CGYmV0nBnwHj0yeRwMtg8rclDw6B6zWlHpwIRWWV7sBAPwfn/krjl wV6DsEXzjZS8GyDqfYSD5ZC/0ivB2ug+M9VQsDPQ+HCcQ+/EcxjbbjQaEwEK0N2UlgsE/qrHn gOhEJT2QQhmH7CYeZevciMIqxPLWflNJwuRvBHYylmdd+SPwwcmyIEkxaODdUhK5cc5+635fs XBHoTWEonvAUcDkVV1d7/57fD8t8lojX+9xtfk8IsO4ITjzrINVPzkYv404dPIHETisnQq7NZ Yy6j1siVkZFypTJKroyLksfsUDCH5IxCZZIfVBmMcqWCOWhQGApyMzVZCq3KeAZxbzRL1/nGB dTc41Q40HoKkwWJtw8/3idZl5GXVcAyBjZdb9KoDA60kaJkID56j9P89apsVf4BtYZ76WsyUH 6yQHGMi5PFBh2Ta1BnC9IgSqDMM9W1OHW638bV+UW+LjTZufrQXXuq62pxCaHN06qkweJFvgX Nt2BN2icD1v6m6yhEGiBGXl5eEj+dSp+rNv5Xn0XBFJIFiJP4Ln5qrfFJjlkuIsZFTGlf5SMa mX8l6WEs+cWp0EpJtC5XmvqreZoJTrSasLL3djteW2jbWV8V3NcZmhxqO/vokujt9Pm5pPd7w /Z+rv/AWQjGW9+x5a474zmpjtHYwT2bLE6jw3fDno6l2XLbuugKi4GVm9ic6K6zPxdMD8eF5d xaSAl588HcDEq72u3SvRot9gpPSLBHbK0f8SFr0n8MUqRagjYnfXI0ysyaFpJDWrKo49ihcNv c6Grx0jVn3K70+KqvOmvVVyY1xEsNWta1bK0caOwdSpzSyC7/4By7cL4uMwI/0JRy9R3H/opn q0PUxGcXf6lvbVgaCN8SNbF57JuV6A7Hx7dNkiMTrq6UsJN39+7Mbvmw5iMZYWAZ5TZcb2D+A WmxD4LIBAAA
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-30.tower-265.messagelabs.com!1560277608!544619!1
X-Originating-IP: [52.27.180.120]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.43.9; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 30150 invoked from network); 11 Jun 2019 18:26:51 -0000
Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR02-VE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-30.tower-265.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 11 Jun 2019 18:26:51 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=73RIOaUHJdMY8qMMs/HXs6JQSJzaxxhTdsqS6Y7uskY=; b=fZh017CToFiUB3rP9YD/nKrHUu0T7oZD1WewtouYx3i43qtQfz77aBXN3zpYxyzcTz01NlfNKeLqtEiVaThwYZ5xXHF53pZMy1FouwnEyzmcDacn0w9aDtZk0I+B9V6FJMgnW1A68Jqba/5ziz5WI1HhPObT0eLJck6kg/XjOPI=
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3506.eurprd03.prod.outlook.com (52.134.80.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Tue, 11 Jun 2019 18:26:46 +0000
Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Tue, 11 Jun 2019 18:26:46 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Italo Busi <italo.busi@huawei.com>
CC: "'mpls@ietf.org'" <mpls@ietf.org>
Thread-Topic: ITU-T LS on MRPS (RFC 8227)
Thread-Index: AdUgdB9l/kr7N5AHQRmUWXnjfygE4AACAc1z
Date: Tue, 11 Jun 2019 18:26:46 +0000
Message-ID: <AM0PR03MB3828FD93BA32BE110B87AB489DED0@AM0PR03MB3828.eurprd03.prod.outlook.com>
References: <91E3A1BD737FDF4FA14118387FF6766B2775D083@lhreml504-mbs>
In-Reply-To: <91E3A1BD737FDF4FA14118387FF6766B2775D083@lhreml504-mbs>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [52.142.119.209]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 5b015c2b-8121-4b33-81a8-08d6ee9a5c90
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(49563074)(7193020); SRVR:AM0PR03MB3506;
x-ms-traffictypediagnostic: AM0PR03MB3506:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <AM0PR03MB35061D3111A227A3731A333B9DED0@AM0PR03MB3506.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 006546F32A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(396003)(346002)(39860400002)(54094003)(51444003)(199004)(189003)(446003)(66556008)(64756008)(81166006)(733005)(66476007)(71200400001)(71190400001)(14454004)(66616009)(76116006)(3846002)(7696005)(76176011)(53936002)(86362001)(72206003)(6436002)(73956011)(54896002)(52536014)(81156014)(91956017)(25786009)(8676002)(66446008)(478600001)(5660300002)(8936002)(4326008)(66946007)(53546011)(6506007)(7736002)(476003)(256004)(33656002)(68736007)(6116002)(606006)(9686003)(54556002)(229853002)(99936001)(236005)(55016002)(6306002)(5024004)(102836004)(14444005)(316002)(6246003)(486006)(186003)(99286004)(66066001)(6916009)(74316002)(26005)(11346002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3506; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: gVHX+/P0GrX8fnJvoZ4mcWVwlzhf+KGeXkSf5/ghHdP46JYdiwr47cNVstNi6i+OT6fpV3gNqdLE2KVWuHAgMSd4AGIpYy/BaaZ8d4m4IICJuMTMg0JOs4waDoPpOgMYxjUml+XFptnkZtT046GmpSPqwlOoC5UENMIVFvx0J7FdiALo7D8/rfajJDBfmwvmV9KOTzub9eTJWw2blv0FD0fA1BoiO1SiZz29j5/Vyb5emrJORFSnfWm270pafqgfreKwxGIETFfzXVUTv6tNscSfPwsA4h1VzT+CTIWVojQgdeDEkCnlE+BBnrpN7strgtllAkekD+QUSaYCqFR9NZlA/TRLx5wujch17T6Se7QswufM0e2KvNmcmjMFk3pczevaEmtPkdCiPaD87XGjgNF+zJ+wG1ictjx6nqHAZYI=
Content-Type: multipart/related; boundary="_004_AM0PR03MB3828FD93BA32BE110B87AB489DED0AM0PR03MB3828eurp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 5b015c2b-8121-4b33-81a8-08d6ee9a5c90
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 18:26:46.4362 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3506
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/s5x7AL-UVe-JPlu0QY6LHI7Pzic>
Subject: Re: [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 18:26:59 -0000

Italo,
I wonder if the question about a 2-node ring has any practical significance?
One could use MPLS-TP Linear ptotection in this case IMHO.

My 2c


Thumb typed by Sasha Vainshtein

From: mpls <mpls-bounces@ietf.org> on behalf of Italo Busi <Italo.Busi@huawei.com>
Sent: Tuesday, June 11, 2019 4:41:27 PM
To: mpls@ietf.org
Subject: [mpls] ITU-T LS on MRPS (RFC 8227)

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

[Image]



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!


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________