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

Dan Li <danli@huawei.com> Wed, 29 December 2010 01:40 UTC

Return-Path: <danli@huawei.com>
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 EE9043A69B7 for <rtg-dir@core3.amsl.com>; Tue, 28 Dec 2010 17:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.149
X-Spam-Level:
X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
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 j4yshhfbcd2F for <rtg-dir@core3.amsl.com>; Tue, 28 Dec 2010 17:40:58 -0800 (PST)
Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id D29813A6979 for <rtg-dir@ietf.org>; Tue, 28 Dec 2010 17:40:58 -0800 (PST)
Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LE6008Z823RA3@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 28 Dec 2010 19:43:03 -0600 (CST)
Received: from [192.168.10.166] ([219.142.19.254]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0LE600KEO23KJO@usaga03-in.huawei.com> for rtg-dir@ietf.org; Tue, 28 Dec 2010 19:43:03 -0600 (CST)
Date: Wed, 29 Dec 2010 09:42:56 +0800
From: Dan Li <danli@huawei.com>
In-reply-to: <4D19502A.3070801@lab.ntt.co.jp>
To: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
Message-id: <6C34185B-A4A7-4E49-87FA-AC77948E1BD2@huawei.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.1082)
Content-type: text/plain; charset="GB2312"
Content-transfer-encoding: quoted-printable
References: <4D19502A.3070801@lab.ntt.co.jp>
Cc: rtg-dir@ietf.org, draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org, rtg-ads@tools.ietf.org
Subject: Re: [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: Wed, 29 Dec 2010 01:41:00 -0000

Hi Tomonori,

Thanks for the careful review!

Please see below.

Thanks,

Dan

在 2010-12-28,上午10:49, Tomonori TAKEDA 写道:

> 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?
[dan] What I mean is in routing process, the lambda label will be presented, for example, lambda labels will be used to identify a lambda link. The identifier field in lambda label format is used to distinguish different lasers (in one node) when they can transmit the same frequency lambda. So the identifier itself may not be used in routing. But I think here we still can say the label format can be used in Signaling and Routing protocols.

> - 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?)
[dan] Yes, you're correct!
> 
> 
> Nits:
> 
> Section 3.1, 3rd paragraph:
> s/standardize/standardized
[dan] ok, draft will be updated.
> 
> -- 
> Tomonori TAKEDA
> NTT Network Service Systems Lab.
> Phone: +81-422-59-7434
>