[mpls] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt
Lizhong Jin <lizho.jin@gmail.com> Mon, 02 September 2013 16:24 UTC
Return-Path: <lizho.jin@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 A5C1B11E8102; Mon, 2 Sep 2013 09:24:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrr8shpRJ5wy; Mon, 2 Sep 2013 09:24:04 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D481A11E8101; Mon, 2 Sep 2013 09:24:03 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id k8so2141677qcq.14 for <multiple recipients>; Mon, 02 Sep 2013 09:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=jrNazSix7Gi/uz7Usa8XfCBPB6R7qQbQcajEjCBv+gc=; b=AziIs7vsUI0IEbfj2ulKt7n5oqS9WfzoAGui4I6PaCJk9fWLusaChiQRVVAEnIyIu5 s0bdxt7Erk/L1CdjTWHCEQAD5Mm1sz9v6WFxMOxQtN62oQa6JEl91/ZWXdPT6yntD/KU kSs8TaZBzTPge4AHuIlx7fEbKJwM3qyKN3oC5DqfCRa0wbcRvV8tmTskB0QuDBkIptcc 5zkoTjY8Ia/dbJyr+sd8tvxYCCzScJYPaSMgv+w5sIBAtIU1Tu4ZNhdsgw00ZaHa9jRA OZBD2i+kbm2m4e3Rh8saeU7pKmfFoupeX55CpSILDLCx49t7ESfGDsyHBHdbROJDklpL 0lvg==
MIME-Version: 1.0
X-Received: by 10.229.129.3 with SMTP id m3mr30219917qcs.13.1378139042053; Mon, 02 Sep 2013 09:24:02 -0700 (PDT)
Received: by 10.49.3.226 with HTTP; Mon, 2 Sep 2013 09:24:01 -0700 (PDT)
Date: Tue, 03 Sep 2013 00:24:01 +0800
Message-ID: <CAH==cJwkxWtRoi9UKeu121SQRu_d+nCGEkKY1g5b+eMf4-pbAw@mail.gmail.com>
From: Lizhong Jin <lizho.jin@gmail.com>
To: rtg-ads@tools.ietf.org
Content-Type: multipart/alternative; boundary="001a1132e5ac0da45e04e569006d"
Cc: rtg-dir@ietf.org, draft-ietf-mpls-targeted-mldp.all@tools.ietf.org, mpls@ietf.org
Subject: [mpls] RtgDir review: draft-ietf-mpls-targeted-mldp-03.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 02 Sep 2013 16:24:05 -0000
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. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html 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-targeted-mldp-03.txt Reviewer: Lizhong Jin Review Date: 2 September 2013 IETF LC End Date: 05 September 2013 Intended Status: Standards Track o Summary: I have some minor concerns about this document that I think should be resolved before publication. o Comments: This document provides the specification for using the LDP P2MP/MP2MP extensions over a Targeted LDP session. It is clearly written. I only have some minor issues which need to be clarified. o Major Issues: No major issues found. o Minor Issues: 1. Section 1 is introduction, but section 1.2, 1.3, 1.4 seem to define the specification, not overview introduction. It is suggest to have a separate section to describe the introduction. 2. Section 1.1, the reference of mLDP RFC is indexed by [mLDP], not [RFC6388] (same for [LDP-UP]). I am not quite sure IETF template allows this, please check. 3. Section 1.2.1, line 176, what if there is IGP neighbors, and there is targeted LDP session between U and D? This is possible in some deployments. 4. Section 1.2.1, line 188, is there a precedence among the different methods, and the operator could define the precedence? 5. Section 3, line 356, how does D know to send label request, not label mapping message? Multicast or unicast from U to D is determined by U, and D could not get this information automatically. Then is there any static configuration required here? 6. Section 3, line 358, the label request messages mentioned in the text should be upstream label request message. It is better to explicit to say this. 7. Section 3, line 382, it is said: While it is possible to do this, it is highly RECOMMENDED that MP2MP LSPs be tunneled through MP2MP LSPs. I do not quite understand this statement. This specification does not describe the mechanism of MP2MP LSPs being tunneled through MP2MP LSPs. From my view, MP2MP LSPs over MP2MP LSPs is not easy, and should resolve the upstream label uniqueness among different upstream nodes. It should be caution to have this recommendations here. Regards Lizhong