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

Dan Li <danli@huawei.com> Fri, 31 December 2010 07:16 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 DD5993A68DD for <rtg-dir@core3.amsl.com>; Thu, 30 Dec 2010 23:16:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.828
X-Spam-Level:
X-Spam-Status: No, score=-3.828 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
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 ERpk-zrrAmsr for <rtg-dir@core3.amsl.com>; Thu, 30 Dec 2010 23:16:06 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8299B3A68D9 for <rtg-dir@ietf.org>; Thu, 30 Dec 2010 23:16:06 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEA003CM6XZGV@szxga03-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEA00FNI6XZGJ@szxga03-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST)
Received: from l00037133 ([10.70.77.125]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEA005PV6XYA4@szxml04-in.huawei.com> for rtg-dir@ietf.org; Fri, 31 Dec 2010 15:17:59 +0800 (CST)
Date: Fri, 31 Dec 2010 15:17:58 +0800
From: Dan Li <danli@huawei.com>
To: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
Message-id: <011d01cba8ba$da07f890$7d4d460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <201012291230.oBTCUo9U008851@imail2.m.ecl.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: Fri, 31 Dec 2010 07:16:08 -0000

Hi Tomonori,

Thanks for your comments! I would like to update the description of Identifier in section 3.2 and 3.3.

OLD
   (3) Identifier: 9 bits

   The identifier field is a per-node assigned and scoped value. This
   field MAY change on a per-hop basis. In all cases but one, a node MAY
   select any value, including zero (0), for this field. Once selected,
   the value MUST NOT change until the LSP is torn down and the value
   MUST be used in all LSP related messages, e.g., in Resv messages and
   label RRO subobjects. The sole special case occurs when this label
   format is used in a label ERO subobject. In this case, the special
   value of zero (0) means that the referenced node MAY assign any
   Identifier field value, including zero (0), when establishing the
   corresponding LSP.
NEW
   (3) Identifier: 9 bits

   The identifier field in lambda label format is used to distinguish different 
   lasers (in one node) when they can transmit the same frequency lambda.
   The identifier field is a per-node assigned and scoped value. This
   field MAY change on a per-hop basis. In all cases but one, a node MAY
   select any value, including zero (0), for this field. Once selected,
   the value MUST NOT change until the LSP is torn down and the value
   MUST be used in all LSP related messages, e.g., in Resv messages and
   label RRO subobjects. The sole special case occurs when this label
   format is used in a label ERO subobject. In this case, the special
   value of zero (0) means that the referenced node MAY assign any
   Identifier field value, including zero (0), when establishing the
   corresponding LSP. 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.

Is this ok?

Thanks,

Dan

----- Original Message ----- 
From: "Tomonori TAKEDA" <takeda.tomonori@lab.ntt.co.jp>
To: <danli@huawei.com>
Cc: <rtg-ads@tools.ietf.org>; <rtg-dir@ietf.org>; <draft-ietf-ccamp-gmpls-g-694-lambda-labels.all@tools.ietf.org>
Sent: Wednesday, December 29, 2010 8:30 PM
Subject: Re: RtgDir review: draft-ietf-ccamp-gmpls-g-694-lambda-labels-10.txt


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