Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard
Italo Busi <Italo.Busi@huawei.com> Thu, 11 May 2017 14:12 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 6030B1314C5; Thu, 11 May 2017 07:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 PFFeE1pe30VQ; Thu, 11 May 2017 07:12:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF28E129AC7; Thu, 11 May 2017 07:05:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DMS65534; Thu, 11 May 2017 14:05:47 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([10.201.109.59]) by LHREML712-CAH.china.huawei.com ([10.201.108.35]) with mapi id 14.03.0301.000; Thu, 11 May 2017 15:05:43 +0100
From: Italo Busi <Italo.Busi@huawei.com>
To: "ietf@ietf.org" <ietf@ietf.org>
CC: "mpls@ietf.org" <mpls@ietf.org>, "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" <draft-ietf-mpls-tp-shared-ring-protection@ietf.org>
Thread-Topic: Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard
Thread-Index: AQHSwFHT6RfRe34k+0+8cXprdYx99aHvEoSQ
Date: Thu, 11 May 2017 14:05:42 +0000
Message-ID: <91E3A1BD737FDF4FA14118387FF6766B157346F2@lhreml504-mbs>
References: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com>
In-Reply-To: <149339519935.2881.8322243003635696392.idtracker@ietfa.amsl.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.243.209]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.59146FBC.02BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2308c4b72cc3415953b99e51bfb7d306
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/HXZ8Ss4yBdd3iBQnhHxORviX1e8>
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
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, 11 May 2017 14:12:14 -0000
I think the draft is ready to be published. I have recently discussed with some authors of the draft some questions for clarification and it might be worthwhile considering minor text changes proposed below to further improve text clarity. 1) Section 4.3.1.2 and 4.3.2.2 The text describing egress node failures imply that, also in case of wrapping and short-wrapping, the ingress node, when notified (by RPS) about egress node failure, will not send traffic to either the working or the protection tunnel (like it does with steering protection). It might be worthwhile adding some explicit text OLD TEXT (Section 4.3.1.2) In one special case where node D fails, all the ring tunnels with node D as egress will become unusable. However, before the failure location information is propagated to all the ring nodes, the wrapping protection mechanism may cause temporary traffic loop: NEW TEXT (Section 4.3.1.2) In one special case where node D fails, all the ring tunnels with node D as egress will become unusable. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable thus it will not send traffic to either the working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes, the wrapping protection mechanism may cause temporary traffic loop: OLD TEXT (Section 4.3.2.2) <...> When node D fails, traffic of LSP1 cannot be protected by any ring tunnels which use node D as the egress node. However, before the failure location information is propagated to all the ring nodes using the RPS protocol, node C switches all the traffic on the working ring tunnel <...> NEW TEXT (Section 4.3.2.2) <...> When node D fails, traffic of LSP1 cannot be protected by any ring tunnels which use node D as the egress node. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable thus it will not send traffic to either the working or the protection tunnel. However, before the failure location information is propagated to all the ring nodes using the RPS protocol, node C switches all the traffic on the working ring tunnel <...> 2) Section 4.3.2 With short-wrapping the two traffic directions of protected LSPs are no longer co-routed under protection switching conditions. This should be mentioned. OLD TEXT With short wrapping protection, data traffic switching is executed only at the node upstream to the failure, and data traffic leaves the ring in the protection ring tunnel at the egress node. This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. NEW TEXT With short wrapping protection, data traffic switching is executed only at the node upstream to the failure, and data traffic leaves the ring in the protection ring tunnel at the egress node. This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. However the two directions of a protected bidirectional LSP are no longer co-routed under protection switching conditions. 3) Section 4.3.2 The difference between wrapping and short-wrapping is in the way protection tunnel is configured. OLD TEXT In the traditional wrapping solution, in normal state the protection ring tunnel is a closed ring, while in the short wrapping solution, the protection ring tunnel is ended at the egress node, which is similar to the working ring tunnel. NEW TEXT In the traditional wrapping solution, the protection ring tunnel is configured as a closed ring, while in the short wrapping solution, the protection ring tunnel is configured as ended at the egress node, which is similar to the working ring tunnel. Thanks, Italo -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: sabato 29 aprile 2017 00:00 To: IETF-Announce Cc: mpls@ietf.org; db3546@att.com; mpls-chairs@ietf.org; draft-ietf-mpls-tp-shared-ring-protection@ietf.org; Eric Gray; Eric.Gray@Ericsson.com Subject: Last Call: <draft-ietf-mpls-tp-shared-ring-protection-05.txt> (Shared-Ring protection (MSRP) mechanism for ring topology) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Shared-Ring protection (MSRP) mechanism for ring topology' <draft-ietf-mpls-tp-shared-ring-protection-05.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-05-12. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes requirements, architecture and solutions for MPLS-TP Shared Ring Protection (MSRP) in a ring topology for point- to-point (P2P) services. The MSRP mechanism is described to meet the ring protection requirements as described in RFC 5654. This document defines the Ring Protection Switch (RPS) Protocol that is used to coordinate the protection behavior of the nodes on MPLS ring. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2680/ https://datatracker.ietf.org/ipr/2681/ https://datatracker.ietf.org/ipr/2682/ https://datatracker.ietf.org/ipr/2683/
- [mpls] Last Call: <draft-ietf-mpls-tp-shared-ring… The IESG
- Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-… Italo Busi
- Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-… Weiqiang Cheng
- Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-… 정태식
- Re: [mpls] Last Call: <draft-ietf-mpls-tp-shared-… Huub van Helvoort