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

Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp> Wed, 29 December 2010 12:28 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 49A223A691E for <rtg-dir@core3.amsl.com>; Wed, 29 Dec 2010 04:28:55 -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 QIPDc1VXbYOT for <rtg-dir@core3.amsl.com>; Wed, 29 Dec 2010 04:28:53 -0800 (PST)
Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by core3.amsl.com (Postfix) with ESMTP id 7718B3A68D8 for <rtg-dir@ietf.org>; Wed, 29 Dec 2010 04:28:53 -0800 (PST)
Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.14.4/8.14.4) with ESMTP id oBTCUpvB018438; Wed, 29 Dec 2010 21:30:51 +0900 (JST)
Received: from mfs5.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 12AE36D33; Wed, 29 Dec 2010 21:30:51 +0900 (JST)
Received: from imail2.m.ecl.ntt.co.jp (imail2-mgr.m.ecl.ntt.co.jp [129.60.144.42]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 05B396D31; Wed, 29 Dec 2010 21:30:51 +0900 (JST)
Received: from imf.m.ecl.ntt.co.jp (webmail.ecl.ntt.co.jp [129.60.39.130]) by imail2.m.ecl.ntt.co.jp (8.13.8/8.13.8) with SMTP id oBTCUo9U008851; Wed, 29 Dec 2010 21:30:50 +0900
Message-Id: <201012291230.oBTCUo9U008851@imail2.m.ecl.ntt.co.jp>
To: danli@huawei.com
From: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
Date: Wed, 29 Dec 2010 21:30:50 +0900
In-Reply-To: <6C34185B-A4A7-4E49-87FA-AC77948E1BD2@huawei.com>
X-Mailer: WebMail V3.7 PL3
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-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 12:28:55 -0000

Hi Dan,

Thanks for your reply.

Please see in-line.

Tomonori

> 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.

Thanks for clarification.

It makes sense to me that lambda labels can be used to in singaling and routing protocols (also in PCEP).

What I was not sure is about the use of the identifier field when used in routing. If the document specifies the use of identifier field for signaling but not for routing, I am fine with the current text. (Otherwise, I think text needs to be added for the use of the identifier field in routing.)

> 
> > - 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!

Thanks for clarification.

I think it would be good to add some text explaining the behavior when non-zero value is assigned to the identifier filed in a label ERO subobject (just for completeness).
 
> > 
> > Nits:
> > 
> > Section 3.1, 3rd paragraph:
> > s/standardize/standardized
> [dan] ok, draft will be updated.