Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
Mach Chen <mach.chen@huawei.com> Thu, 26 May 2016 06:21 UTC
Return-Path: <mach.chen@huawei.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FB512B071; Wed, 25 May 2016 23:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 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=-1.426, 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 Nh4J15EI5Ey8; Wed, 25 May 2016 23:21:15 -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 91AC612D0A0; Wed, 25 May 2016 23:21:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKU44338; Thu, 26 May 2016 06:21:11 +0000 (GMT)
Received: from SZXEMA416-HUB.china.huawei.com (10.82.72.35) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 26 May 2016 07:21:08 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.42]) by SZXEMA416-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0235.001; Thu, 26 May 2016 14:21:04 +0800
From: Mach Chen <mach.chen@huawei.com>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
Thread-Index: AdGe+Z/lFOzQc8O7SFSbqLe7ce8oewAG1OFwA2v05+AAAARS8AJlk/FwAAHw8kAAAKspgAABGawwAACm3lAAKmREgA==
Date: Thu, 26 May 2016 06:21:03 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC6FA05@SZXEMA510-MBX.china.huawei.com>
References: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206C81@SZXEMA510-MBX.china.huawei.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28C206D6F@SZXEMA510-MBX.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE48162EBD1D@ESESSMB301.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC6CF3E@SZXEMA510-MBX.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE48162EBF6F@ESESSMB301.ericsson.se> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE28CC6CF83@SZXEMA510-MBX.china.huawei.com> <4A1562797D64E44993C5CBF38CF1BE48162EC0EA@ESESSMB301.ericsson.se>
In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48162EC0EA@ESESSMB301.ericsson.se>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.102.135]
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.0A020202.574695D7.0142, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.42, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: c1bd2077fdb78ac4453c9ffedee5bcb7
Archived-At: <http://mailarchive.ietf.org/arch/msg/pals/KQnlmcl0fQ7RDBcN9i63qSt-B_k>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org" <draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org>, "pals@ietf.org" <pals@ietf.org>
Subject: Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 May 2016 06:21:24 -0000
Thanks Daniele! We have uploaded the version-07 to address the RtgDir review comments. Htmlized: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-07 Best regards, Mach > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: Wednesday, May 25, 2016 6:03 PM > To: Mach Chen; <rtg-ads@ietf.org> (rtg-ads@ietf.org) > Cc: rtg-dir@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org; > pals@ietf.org > Subject: RE: RtgDir review: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > That's perfect! > > BR > Daniele > > > -----Original Message----- > > From: Mach Chen [mailto:mach.chen@huawei.com] > > Sent: mercoledì 25 maggio 2016 11:47 > > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; > > <rtg-ads@ietf.org> > > (rtg-ads@ietf.org) <rtg-ads@ietf.org> > > Cc: rtg-dir@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir- > > lsp.all@tools.ietf.org; pals@ietf.org > > Subject: RE: RtgDir review: > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > Hi Daniele, > > > > Yes, your understanding is right. How about add the following text: > > > > The U-bit and F-bit are defined Section 3.3 RFC5036. Since the PSN > > Tunnel Binding TLV is an optional TLV, the U-bit MUST be set to 1 so > > that a receiver MUST silently ignore this TLV if unknown to it, and > > continue processing the rest of the message. > > A receiver of this TLV is not allowed to forward the TLV further when > > it does not know the TLV. So, the F-bit MUST be set to 0. > > > > Thanks, > > Mach > > > > > -----Original Message----- > > > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > > > Sent: Wednesday, May 25, 2016 5:21 PM > > > To: Mach Chen; <rtg-ads@ietf.org> (rtg-ads@ietf.org) > > > Cc: rtg-dir@ietf.org; > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org; > > > pals@ietf.org > > > Subject: RE: RtgDir review: > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > Hi Mach, > > > > > > Ok, let me try to summarize. > > > > > > The draft defines a new TLV for the LDP Mapping Message (RFC 5036 > > > section > > > 3.5.7) which I guess would end up in the "optional parameters" field > > > (the text > > > says: "contains 0 or more parameters, each encoded as a TLV"). > > > Then section 3.3 mandates how to build those TLVs (U, F and so on). > > > > > > If my understanding correct? If yes I suggest to state it in the > > > text and possibly add why the U bit is always 1 in your case and the > > > F bit is > > always 0. > > > > > > Thanks for the explanation > > > Daniele > > > > > > > -----Original Message----- > > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > > Sent: mercoledì 25 maggio 2016 11:02 > > > > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; > > > > <rtg-ads@ietf.org> > > > > (rtg-ads@ietf.org) <rtg-ads@ietf.org> > > > > Cc: rtg-dir@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir- > > > > lsp.all@tools.ietf.org; pals@ietf.org > > > > Subject: RE: RtgDir review: > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > > > Hi Daniele, > > > > > > > > > -----Original Message----- > > > > > From: Daniele Ceccarelli > > > > > [mailto:daniele.ceccarelli@ericsson.com] > > > > > Sent: Wednesday, May 25, 2016 4:08 PM > > > > > To: Mach Chen; <rtg-ads@ietf.org> (rtg-ads@ietf.org) > > > > > Cc: rtg-dir@ietf.org; > > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp.all@tools.ietf.org; > > > > > pals@ietf.org > > > > > Subject: RE: RtgDir review: > > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > > > > > Hi Mach, > > > > > > > > > > Thanks for the update. > > > > > There is just one outstanding point: > > > > > > > > > > > • Section 2.1: “LDP Label Mapping message” missing reference. > > > > > > And why the Type field starts with 1 and 0? > > > > > Thanks for adding the reference but I still don't get why the > > > > > Type field starts with 1 and 0. > > > > > > > > The first two bits are U-bit and F-bit, which are defined in > > > > Section > > > > 3.3 of RFC5036. How about adding the follow text: > > > > > > > > For this TLV, the Unknown TLV bit (U-bit) (Section 3.3 of RFC5036) > > > > is set to 1, and the Forwarding unknown bit (F-bit) (Section 3.3 > > > > of > > > > RFC5036) is > > > set to 0. > > > > > > > > > One more comment that I lost during the first iteration: why do > > > > > you define the "flag" field in figure 3 and then below have a > > > > > further figure showing C, S, T and the must be zero field? I'd > > > > > directly put the C,S,T and must be zero fields in place of the > > > > > Flag field in figure 3. It > > > > helps with readability IMHO. > > > > > > > > OK, will put them back to the TLV and remove the flags figure. > > > > > > > > > > > > Hope above address your comments! > > > > > > > > Thanks, > > > > Mach > > > > > > > > > > > > > > > BR > > > > > Daniele > > > > > > > > > > > -----Original Message----- > > > > > > From: Mach Chen [mailto:mach.chen@huawei.com] > > > > > > Sent: venerdì 13 maggio 2016 09:25 > > > > > > To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>; > > > > > > <rtg-ads@ietf.org> > > > > > > (rtg-ads@ietf.org) <rtg-ads@ietf.org> > > > > > > Cc: rtg-dir@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir- > > > > > > lsp.all@tools.ietf.org; pals@ietf.org > > > > > > Subject: RE: RtgDir review: > > > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > > > > > > > Hi Daniele, > > > > > > > > > > > > Thanks for the detailed review and valuable comments! > > > > > > > > > > > > Please see my responses inline... > > > > > > > > > > > > I also attached a diff that shows the updates that try to > > > > > > address your comments. If you are OK with the updates, I will > > > > > > submit > > it then. > > > > > > > > > > > > Thanks, > > > > > > Mach > > > > > > > > > > > > > From: Daniele Ceccarelli > > > > > > > Sent: lunedì 25 aprile 2016 19:04 > > > > > > > To: <rtg-ads@ietf.org> (rtg-ads@ietf.org) > > > > > > > Cc: 'rtg-dir@ietf.org'; > > > > > > > 'draft-ietf-pals-mpls-tp-pw-over-bidir- > > > > lsp.all@ietf.org' > > > > > > > Subject: RtgDir review: > > > > > > > draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > > > > > > > > > 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-pals-mpls-tp-pw-over-bidir-lsp-06 > > > > > > > Reviewer: Daniele Ceccarelli Review Date: April 25 2016 IETF > > > > > > > LC End Date: - Intended Status: Standard Track > > > > > > > Summary: > > > > > > > • I have some minor concerns about this document that I > > > > > > > think should be resolved before publication. > > > > > > > Comments: > > > > > > > • What the drafts is proposing as protocol modification is > > > > > > > clear and also the operation section are pretty > > > > > > > straighforward. What needs to be improved is the > > > > > > > introduction part, which should be reviewed by a native English > speaker. > > > > > > > Also the IANA section should be > > > > made clearer. > > > > > > > > > > > > Thanks for your suggestion, I assume the RFC editor will do > > > > > > another review once the document progressed to that stage. > > > > > > > > > > > > > Major Issues: > > > > > > > • No major issues found > > > > > > > Minor Issues: > > > > > > > • Abstract: “In addition, the user traffic may traverse > > > > > > > through multiple transport networks.” Maybe is worth > > > > > > > elaborating a bit this sentence saying that the extensions > > > > > > > defined in this draft apply both to SS- > > > > > > PW and MS-PW. > > > > > > > > > > > > How about this: > > > > > > > > > > > > "Many transport services require that user traffic, in the > > > > > > form of Pseudowires (PW), be delivered on a single co-routed > > > > > > bidirectional tunnel or two tunnels that share the same routes. > > > > > > This document defines an optional extension to LDP that > > > > > > enables the binding between PWs and the underlying TE tunnels. > > > > > > The extension applies to both SS-PW and > > > > > MS-PW." > > > > > > > > > > > > > • In the abstract it is said that a PW is linked to an LSP > > > > > > > but then in the intro it is said that the PW binding is to a tunnel. > > > > > > > Can you clarify this? I’d say that it should be linked to a tunnel, > right? > > > > > > > > > > > > Yes, it's better to use tunnel, I have updated the abstract to > > > > > > make Abstract and Introduction have the consistent usage. > > > > > > Please see above the new text for Abstract. > > > > > > > > > > > > > • Intro: “PW-to-PSN Tunnel binding has become increasingly > > > > > > > common and important in many deployment scenarios”. I guess > > > > > > > you mean an automatic binding done via a signaling protocol? > > > > > > > > > > > > No, this sentence just brings the requirements of explicit PW > > > > > > to PSN tunnel binding, whatever it is automatic signaling or > > > > > > manual > > > configuration. > > > > > > > > > > > > > • What do you mean with “may traverse through different routes”? > > > > > > > I suggest leaving “may traverse multiple networks or domains. > > > > > > > > > > > > Here the "routes" means "paths". > > > > > > > > > > > > How about: "...may traverse through different paths or networks"? > > > > > > > > > > > > > • Intro and Figure 1: could be example be made a bit more > > > > > > > generic with a network between the PEs? With directly > > > > > > > connected PEs it doesn’t seem a realistic and generic enough > > example. > > > > > > > > > > > > > > > > > > > • Intro: suggest removing “As mentioned above”. > > > > > > > > > > > > OK. > > > > > > > > > > > > > • The name of the draft explicitly mentions MPLS-TP but in > > > > > > > the rest of the draft there is no mention of it, just the > > > > > > > much more general Packet Switching Network term is used. > > > > > > > > > > > > Indeed, that's the intention. This work was triggered by the > > > > > > discussion of MPLS-TP. But with the progress of this draft and > > > > > > discussion within the WG, there is a consensus that this > > > > > > technique is a general solution that can actually apply to > > > > > > both TP and > > non-TP cases. > > > > > > > > > > > > > • Section 2: “This document defines a new optional TLV, > > > > > > > PSN Tunnel Binding TLV, to communicate tunnel/LSPs selection > > > > > > > and binding requests > > > > > > between PEs. > > > > > > > “ The binding request is between PEs? Or between an PW and a > > > > > > > Tunnel (or LSP?) between two PEs? > > > > > > > > > > > > Between PEs of an PW. > > > > > > > > > > > > > • Section 2: Strict binding vs Co-routed binding: from the > > > > > > > description it seems that the first one is strict and the > > > > > > > second one is > > > > > “loose” > > > > > > > (in the sense that the PE can accept the request or not). > > > > > > > Don’t both apply > > > > > > to co-routed LSPs? > > > > > > > > > > > > Yes, both can apply to co-routed LSPs. But for "strict" mode, > > > > > > if the egress PE must bind to the specified tunnel by the > > > > > > ingress PE, otherwise, the binding will not success. The "co-routed" > > > > > > mode gives the egress PE the use alternative tunnel. > > > > > > > > > > > > > • Section 2: ”The terminology "LSP" is identical to the "LSP tunnel" > > > > > > > defined in Section 2.1 of [RFC3209], which is uniquely > > > > > > > identified by the SESSION object together with > > > > > > > SENDER_TEMPLATE (or > > > > > > > FILTER_SPEC) object that consists of LSP ID and Tunnel > > > > > > > endpoint address.” Why is the draft considering only signaled LSPs? > > > > > > > Doesn’t it apply also to centrally > > > > > > provisioned ones? (e.g. NMS or SDN). > > > > > > > > > > > > The main purpose here is to give a reference to the term of "LSP" > > > > > > and "tunnel", hence to eliminate the confusion of when use > > > > > > these in the following sections. As for the NMS and SDN based > > > > > > TE LSP/Tunnel, technically, it can apply to as well only if > > > > > > the TE LSP/Tunnel has the LSP number, node ID etc. information. > > > > > > > > > > > > > • Section 2.1: “LDP Label Mapping message” missing reference. > > > > > > > And why the Type field starts with 1 and 0? > > > > > > > > > > > > Good catch, will add a reference here. > > > > > > > > > > > > > > > > > > > Nits: > > > > > > > • Abstract s/ traverse through multiple/ traverse multiple • > > > > Introduction: > > > > > > > “Pseudowire (PW) Emulation Edge-to-Edge (PWE3)”. I suggest > > > > > > > removing (PW), it’s already included into PWE3. > > > > > > > > > > > > OK. > > > > > > > • Intro: s/ a bidirectional circuits/ a bidirectional > > > > > > > circuit > > > > > > > > > > > > OK. > > > > > > > > > > > > • Intro: suggest > > > > > > > rephrasing: “Bidirectional LSPs share fate and simplify the > > > > > > > routing of a protection path also consisting of > > > > > > > bidirectional LSPs because working and protection paths have to be > disjoint.” > > > > > > > > > > > > OK. > > > > > > > > > > > > > • Intro: s/ there are a large number/ there is a large > > > > > > > number > > > > > > > > > > > > OK. > > > > > > > > > > > > • Intro:s/to be > > > > > > > carried/are carried > > > > > > > > > > > > OK. > > > > > > > > > > > > • Intro:s/there are a number/there is a number > > > > > > > > > > > > OK. > > > > > > > > > > > > • Intro: s/ > > > > > > > traffic belongs/traffic belonging > > > > > > > > > > > > OK. > > > > > > > > > > > > • Intro: (suggestion) s/(PE1-P3-PE2)/ > > > > > > > (PE2-P3-PE1) since we are speaking about directionality it > > > > > > > makes more sense to list the nodes of the path in the > > > > > > > reverse > > direction. > > > > > > > > > > > > OK. > > > > > > > > > > > > > • Intro: s/ The similar problems/A similar problem > > > > > > > > > > > > OK. > > > > > > > > > > > > >• Intro: s/ won't/does not > > > > > > > > > > > > OK. > > > > > > >•Intro: s/ In this document, it introduces/This document > > > > > > >introduces BR Daniele > > > > > > > > > > > > OK. > > > > > > > > > > > > >
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Daniele Ceccarelli
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Andrew G. Malis
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Mach Chen
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Daniele Ceccarelli
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Mach Chen
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Daniele Ceccarelli
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Mach Chen
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Daniele Ceccarelli
- Re: [Pals] RtgDir review: draft-ietf-pals-mpls-tp… Mach Chen