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

From: Tomonori TAKEDA <[email-masked]>
Date: Tue, 28 Dec 2010 11:49:14 +0900

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

---

From: Dan Li <[email-masked]>
Date: Wed, 29 Dec 2010 09:42:56 +0800

Hi Tomonori,

Thanks for the careful review!

Please see below.

Thanks,

Dan

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

>  use the assigned value for the identifier field in a Label object in
[dan] Yes, you're correct!
> s/standardize/standardized
[dan] ok, draft will be updated.

---

From: Tomonori TAKEDA <[email-masked]>
Date: Wed, 29 Dec 2010 21:30:50 +0900

Hi Dan,

Thanks for your reply.

Please see in-line.

Tomonori

> [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 t…

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

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

---

From: Dan Li <[email-masked]>
Date: Fri, 31 Dec 2010 15:17:58 +0800

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

---

From: Tomonori TAKEDA <[email-masked]>
Date: Sat, 01 Jan 2011 00:03:50 +0900

Hi Dan,

Thanks for your reply.

The proposed text is good for me.

Tomonori