[RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt

Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp> Tue, 28 December 2010 02:52 UTC

Return-Path: <takeda.tomonori@lab.ntt.co.jp>
X-Original-To: rtg-dir@core3.amsl.com
Delivered-To: rtg-dir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E493A690B for <rtg-dir@core3.amsl.com>; Mon, 27 Dec 2010 18:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.09
X-Spam-Level:
X-Spam-Status: No, score=-100.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ViuX57NYyDXw for <rtg-dir@core3.amsl.com>; Mon, 27 Dec 2010 18:52:21 -0800 (PST)
Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by core3.amsl.com (Postfix) with ESMTP id 89B4C3A6909 for <rtg-dir@ietf.org>; Mon, 27 Dec 2010 18:52:21 -0800 (PST)
Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id oBS2sPB7026386; Tue, 28 Dec 2010 11:54:25 +0900 (JST)
Received: from mfs6.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2E7E365F1; Tue, 28 Dec 2010 11:54:25 +0900 (JST)
Received: from imail2.m.ecl.ntt.co.jp (imail2.m.ecl.ntt.co.jp [129.60.5.247]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 2878265EB; Tue, 28 Dec 2010 11:54:25 +0900 (JST)
Received: from [127.0.0.1] ([129.60.80.55]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id oBS2rxgq024474; Tue, 28 Dec 2010 11:54:25 +0900
Message-ID: <4D19502A.3070801@lab.ntt.co.jp>
Date: Tue, 28 Dec 2010 11:49:14 +0900
From: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: rtg-ads@tools.ietf.org
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org
Subject: [RTG-DIR] RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtg-dir>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Dec 2010 02:52:22 -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-ccamp-gmpls-g-694-lambda-labels-10.txt
Reviewer: Tomonori Takeda
Review Date: 28 December 2010
IETF LC End Date: Unknown
Intended Status: Standards Track


Summary:
I have some minor concerns about this document that I think should be
resolved before publication.


Comments:
This document is well written and easy to read. I have several nits and
one minor question.


Major Issues:
No major issues found.


Minor Issues:

Section 3.2 (and Section 3.3):
Text on the identifier field is a bit hard to understand.
- In the abstract, it says that the label format defined in this
  document can be used in GMPLS signaling and routing protocols.
  However, it seems that text from Section 3.2 (3) Identifier applies to
  signaling only. Does it mean that Identifier field is set to zero when
  used in routing, and set to a value according to Section 3.2 (3)
  Identifier when used in signaling?
- I can not simply understand text regarding use of identifier in a
  label ERO subobject. Does it mean that when non-zero value is assigned
  to the identifier field in a label ERO subobject, the referenced node
  MUST use the assigned value for the identifier field in the
  corresponding LSP related messages? (e.g., the referenced node MUST
  use the assigned value for the identifier field in a Label object in
  Resv message?)


Nits:

Section 3.1, 3rd paragraph:
s/standardize/standardized

-- 
Tomonori TAKEDA
NTT Network Service Systems Lab.
Phone: +81-422-59-7434