Re: [mpls] RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt

Mach Chen <mach.chen@huawei.com> Tue, 28 February 2017 01:59 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 66028129471; Mon, 27 Feb 2017 17:59:03 -0800 (PST)
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 5DRf28IyPOLy; Mon, 27 Feb 2017 17:59:01 -0800 (PST)
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 39E0212948C; Mon, 27 Feb 2017 17:59:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHW44855; Tue, 28 Feb 2017 01:58:57 +0000 (GMT)
Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 28 Feb 2017 01:58:56 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.116]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Tue, 28 Feb 2017 09:58:52 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Weiqiang Cheng <chengweiqiang@chinamobile.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt
Thread-Index: AQHSjcZujP4pQeKD5EC3MI1pw61Qg6F9rZYQgAACWzA=
Date: Tue, 28 Feb 2017 01:58:52 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDCF659@SZXEMA510-MBX.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28FDCEF54@SZXEMA510-MBX.china.huawei.com> <008701d29164$ab14cd30$013e6790$@com>
In-Reply-To: <008701d29164$ab14cd30$013e6790$@com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.194.201]
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.0A020204.58B4D962.0123, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 69fee7a0d8ae4bdae2fbab47d8a34b48
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/C7M0bwbDFdgHcu5_UXEvM8fRBis>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-tp-shared-ring-protection@ietf.org" <draft-ietf-mpls-tp-shared-ring-protection@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
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, 28 Feb 2017 01:59:03 -0000

Hi Weiqiang,

Thanks for considering the comments, if there are any doubts about comments, I'm happy to clarify.

Best regards,
Mach

> -----Original Message-----
> From: Weiqiang Cheng [mailto:chengweiqiang@chinamobile.com]
> Sent: Tuesday, February 28, 2017 9:48 AM
> To: Mach Chen <mach.chen@huawei.com>;; rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org; draft-ietf-mpls-tp-shared-ring-protection@ietf.org;
> mpls@ietf.org
> Subject: 答复: RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-
> 04.txt
> 
> Hi Mach,
> Thank you very much for your valuable comments.
> We authors will update the draft accordingly soon.
> 
> B.R.
> Weiqiang Cheng
> 
> -----邮件原件-----
> 发件人: Mach Chen [mailto:mach.chen@huawei.com]
> 发送时间: 2017年2月27日 18:05
> 收件人: 'rtg-ads@ietf.org';
> 抄送: 'rtg-dir@ietf.org';; 'draft-ietf-mpls-tp-shared-ring-protection@ietf.org';;
> mpls@ietf.org
> 主题: RtgDir review: draft-ietf-mpls-tp-shared-ring-protection-04.txt
> 
> Hello,
> 
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see 
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
> 
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
> 
> Document: draft-ietf-mpls-tp-shared-ring-protection-04.txt
>  Reviewer: Mach Chen
>  Review Date: 2017/2/23
>  IETF LC End Date:
>  Intended Status: Standards Track
> 
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
> 
> Comments:
> This document may need some paragraph restructuration or adjustment to
> make it more readable, for example , before jumping into the detail of some
> processes, it's better to give some introduction to the scenarios and relevant
> conditions, and the used terms need to be defined before being used.
> 
> Major Issues:
> No major issues found.
> 
> Minor Issues:
> 
> 1.
> The implicit fundamental pre-condition of the proposed MSRP is that, for
> each protected LSP, the egress and the  ingress LSR have to negotiate (or
> through NMS, or static configurations) the LSP label that will be pushed by
> the ingress. The label has to be a label that the egress must know how to
> handle it, otherwise, when the packet exits the ring tunnel, the packet will
> be mis-forwarded to non-intended node or dropped. This condition and
> probably the relevant mechanisms  should be explicitly pointed out and
> described in the document.
> 
> 2.
> Section 4.1
> The Figure of "the logical layers of the ring" shows the innermost service is
> PW, is this document only applies to PW or other applications will be included.
> If it's later, some modifications are needed, and you need to check the whole
> document to make the relevant descriptions and usages consistent.
> Figure 2 has the same problem.
> 
> 3.
> Section 4.1.3
> s/The clockwise working ring tunnel label RcW_D/ The clockwise working ring
> tunnel label of RcW_D And since RcW_D identifies a ring tunnel, not a label,
> and the author seems intend to use RcW_D(X) to identify a ring tunnel label,
> I'd suggest to add some clarification text to this notation.
> 
> 4.
> Section 4.4.1
> Suggest to move Figure 11 to under "Bullet  1.  Single-node interconnected
> rings."
> 
> 5.
> Section 4.4.4, the penultimate paragraph "...LSP1->R1cW_F&A(D)-
> >R1aP_F&A(D->C->B->A)->R2cW_I(A->F->G->H->I)->LSP1.", what's reason
> to add "R1cW_F&A(D)" into the switching path? Seems it's redundant.
> 
> 6.
> Section 4.4.3,
> In my understanding, the ring tunnels to virtual interconnected group are
> shared by all LSPs that needed to be forwarded to other rings, right? If so, it's
> better to add some text to explicitly state this.
> 
> 
> 7.
> Section 5.1
> "   When the failure has cleared and the Wait-to-Restore (WTR) timer has
>    expired, the nodes sourcing RPS requests MUST drop their respective
>    switches (tail end) and MUST source an RPS request carrying the NR
>    code.  The node receiving from both directions such an RPS request
>    (head end) MUST drop its protection switches."
> 
> Above text introduces the "tail end" and "Head end" tems, but the
> document does not have detail definition and introduction to these terms.
> Suggest to give the definition of these term in the terminology and notation
> section.
> 
> 8.
> Section 5.1
> "A destination node is a node that is adjacent to a node that
>    identified a failed link."
> 
> Based on the above text, the "destination node" cannot be uniquely
> determined, since a node in a ring has two adjacent nodes. Some clarification
> or more accurate description is needed.
> 
> 9.
> Section 5.1.2
> s/sane ring/same ring
> 
> 10.
> Section 5.1.3.  Ring Node RPS States
> 
> Are those RPS states per node or per ring tunnel or per egress?  Whatever
> for either case, the document should state it explicitly.
> 
> And according to the explanation of each state, seems that the states are
> mutex each other. Considering the steering mode, seems that a node may
> be at both switching and pass-through state, right?
> 
> BTW, for those RPS codes, it's better to add a reference to the section
> (Section 5.2.1.1) to give a hint to the reader that there will be detailed
> explanation in the following sections.
> 
> 11.
> Section 5.1.3.2
> 
> "A node in the switching state MUST terminate RPS requests flow in
>    both directions."
> 
> If a node in the switching state terminates RPS requests, how does the
> steering switching mode work?
> 
> 12.
> Section 5.1.  RPS Protocol
> "The described RPS protocol uses the short-
>    wrapping mechanism described in section 4.3.2 as an example."
> Are there any differences when the RPS protocol used for wrapping and
> steering, if no, it should be stated clearly. Otherwise, it needs to specify the
> differences, or for each switching mode, define its procedures and state
> machine.
> 
> 13.
> Section 5.1.3.2.  Switching State,
> 
> The third paragraph describes the rules in case of unidirectional failure, but
> reader can not recognized this only when read the next paragraph. This
> section needs some restructure to make it more readable. BTW, since there
> are differences between unidirectional failure and bidirectional failure, there
> need some text to describe the rules and procedures for the bidirectional
> case IMHO
> 
> 14.
> Section 5.2.2.  Initial States
> a)
> It just lists a table and let the reader to guess the meaning, it's better to add
> some clarification text to help the reader understand the meaning and
> intention.
> 
> b)
> In addition:
> 
>            |  B  |  Pass-through               |  N/A           |
>             |     |   Working: no switch        |                |
>             |     |   Protection: pass through  |                |
> For pass-through state, why the working and protection tunnel states are
> different?
> 
> c)
> |  D  |  Idle - LW                  |  NR            |
> 
> What is the LW?  I guess it means "Lock of Working", but it needs to be
> expanded it when first use.
> 
> Best regards,
> Mach
> 
>