Re: [mpls] ITU-T LS on MRPS (RFC 8227)
Huub van Helvoort <huubatwork@gmail.com> Thu, 13 June 2019 08:57 UTC
Return-Path: <huubatwork@gmail.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 5FCE712027E for <mpls@ietfa.amsl.com>; Thu, 13 Jun 2019 01:57:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.044
X-Spam-Level:
X-Spam-Status: No, score=-0.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_DISPTO=0.249, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jSoPhSfpENUZ for <mpls@ietfa.amsl.com>; Thu, 13 Jun 2019 01:57:03 -0700 (PDT)
Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF7412006A for <mpls@ietf.org>; Thu, 13 Jun 2019 01:57:02 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id k8so30034484edr.11 for <mpls@ietf.org>; Thu, 13 Jun 2019 01:57:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:cc:references:from:message-id :disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=H4qbz8BppbyCb+5OKDfKnyQ7TH3ys70tcgx7cjvKkn8=; b=CkJOyQPSE0gKzMNAipzcxY4hFIQsTMB/vVGfEFXeBIoiEbrZYWZwYUqAQN7uKPEH78 +HCPIqwdLLfNZYwWVBs1HJW1+oSlsMr0ze3jDV90XktY9GzMl39oErYjtHtS2fBwL0qd ntJmDPZZFnVtYLUv2nutJIGmhrOacaDLHcINUjH+WVOS653pxfnABTWrBkIPMBOf4pCR HXiOE2m7rxcekEYReCEpYHwxCOoPN37U7Z3QYHrVi7iQZWBflVQF/C6XDgr+mRG+M0ZO WM0AI/WHHEpPrfp7XeDR+bAn92dfCIHzIWs3BKidqOJCauLgBnJ4bg7XuvLkmzHhSVOF yB3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:cc:references:from :message-id:disposition-notification-to:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=H4qbz8BppbyCb+5OKDfKnyQ7TH3ys70tcgx7cjvKkn8=; b=P8waKT9ZqU8BWOfPWHTS3IlcWCqvFibK7bY+mOCztWKGAuYRww8IwzOc/cLNiZPy7k CFrqta8/+XfOcNzF7IPLeaIJIVu+t0ZEO4em4L6U8BMNFqbT0cZs8+dR+0+JuJhDeLLk fVank4asPUedPgWmmFV9/uvlBq8aInBD5H9T3d0SQad//n2Uf3jwLYbsSQ7ko0tqm15o 9Z8aLJD/5BaM4578HhPYIKj2FiyudhLI6oGwdN4WG/FTI1v9yyLLj4Fs5dNemq1AeWTb qPvKx3t4tNMDMHNu0W18i7prodLHWPygypaiI5+LKfjNjMM+TofQk1nSdFBt1goJK3EU 2I7w==
X-Gm-Message-State: APjAAAVIFNlCDXs57I1dCTKCVwlk4qKmhGRBkPvqFxxDKq+wKN0zsTTU 7UDzjycSCcpiWA6/bG0QGQzMxw45
X-Google-Smtp-Source: APXvYqxtRgXiKl9LmfDnSXTY6WNSkvQftCnY09+1mbKaEJ7S+1X7SlOo01ugQVswB6kew1HaEglY0g==
X-Received: by 2002:a50:86ea:: with SMTP id 39mr68696156edu.184.1560416221148; Thu, 13 Jun 2019 01:57:01 -0700 (PDT)
Received: from McAsterix.local ([2a02:a211:8e81:2e00:b16f:9155:b1b7:fd37]) by smtp.gmail.com with ESMTPSA id o22sm729203edc.37.2019.06.13.01.57.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Jun 2019 01:57:00 -0700 (PDT)
Reply-To: huubatwork@gmail.com
To: 류정동 <ryoo@etri.re.kr>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, Italo Busi <italo.busi@huawei.com>
Cc: "'mpls@ietf.org'" <mpls@ietf.org>
References: <91E3A1BD737FDF4FA14118387FF6766B2775D083@lhreml504-mbs> <AM0PR03MB3828FD93BA32BE110B87AB489DED0@AM0PR03MB3828.eurprd03.prod.outlook.com> <5B4A6CBE3924BB41A3BEE462A8E0B75A870FA3B0@SMTP2.etri.info>
From: Huub van Helvoort <huubatwork@gmail.com>
Message-ID: <687c5c39-6223-e004-cc2b-2e6ffa9b22ab@gmail.com>
Date: Thu, 13 Jun 2019 10:56:59 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <5B4A6CBE3924BB41A3BEE462A8E0B75A870FA3B0@SMTP2.etri.info>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/MbUuosR0o_TxOi6WewWW9epoDMg>
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: Thu, 13 Jun 2019 08:57:06 -0000
Indeed the two node ring protection could be replaced by a linear protection
if this is the final configuration. It may be possible that in the (near-) future
the ring will grow by adding more ring nodes.
to be determined, similar in ring protection a short path and a long path have
to be determined.
Based on that knowledge each node will be able to send the appropriate
Italo and Sasha,
I am not sure about whether a two node ring has any practical significance. I think that linear protection would be more appropriate. Nevertheless, I also think it is important to know the extent to which any protocol is applied.
Please, see my responses inline below starting with [JR]:
Best regards,
Jeong-dong
보낸 사람 : "Alexander Vainshtein" <Alexander.Vainshtein@ecitele.com>보낸 날짜 : 2019-06-12 03:27:30 ( +09:00 )받는 사람 : Italo Busi <italo.busi@huawei.com>제목 : Re: [mpls] ITU-T LS on MRPS (RFC 8227)
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
Sent: Tuesday, June 11, 2019 4:41:27 PM
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/" rel="nofollow">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
[JR] I don’t think the common view on which span is short or long would solve the problem. The important thing is how node B knows which span should be used for selecting/bridging the traffic, when node A detects a unidirectional failure. Distinction between the short path and the long path is required because the traffic will be moved away from the short path, which has the failure, after protection switching.
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
[JR] We cannot pre-assign the short and long paths to two spans. The span that has a failure should be the short span and the traffic should be switched away from the short span. (Of course, we can define the failed span as the long span assuming the traffic will be moved to the short span. But, normally, a failed span is shorter than the remaining spans on a ring.)
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
[JR] I think we need a short/long span indication in a RPS protocol message if we want to cover a two node ring. My conculsion would be that the RPS protocol defined in RFC 8227 will not work on a two node ring.
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
-- ================================================================ Always remember that you are unique...just like everyone else...
- [mpls] ITU-T LS on MRPS (RFC 8227) Italo Busi
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) 류정동
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Loa Andersson
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Huub van Helvoort
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Jiangyuanlong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Ryoo, Jeong-dong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Ryoo, Jeong-dong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Ryoo, Jeong-dong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Italo Busi
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Ryoo, Jeong-dong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Huub van Helvoort
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Italo Busi
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Huub van Helvoort
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Loa Andersson
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Alexander Vainshtein
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Ryoo, Jeong-dong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Jiangyuanlong
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Huub van Helvoort
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Weiqiang Cheng
- Re: [mpls] ITU-T LS on MRPS (RFC 8227) Italo Busi