Re: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt

Fatai Zhang <> Thu, 05 September 2013 08:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D934811E80E2; Thu, 5 Sep 2013 01:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.219
X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rsx6i-XcF19q; Thu, 5 Sep 2013 01:03:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4CF4011E80DC; Thu, 5 Sep 2013 01:03:20 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id AVB55913; Thu, 05 Sep 2013 08:03:19 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 5 Sep 2013 09:02:47 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 5 Sep 2013 09:02:53 +0100
Received: from ([]) by ([]) with mapi id 14.03.0146.000; Thu, 5 Sep 2013 16:02:41 +0800
From: Fatai Zhang <>
To: Leeyoung <>, "" <>
Thread-Topic: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt
Thread-Index: AQHOqg5K2IUjQYV0ckGMj1OW7u5h2w==
Date: Thu, 05 Sep 2013 08:02:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF85CA61930SZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "" <>, "" <>, "" <>
Subject: Re: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Sep 2013 08:03:26 -0000

Hi Young and all,

Thanks for your comments.

All Nits should be accepted.

Please see more in-line to check if you are happy with the proposed updates and the clarification.

Best Regards


From: [] On Behalf Of Leeyoung
Sent: Thursday, September 05, 2013 12:27 AM
Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt


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

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-signaling-g709v3-11.txt
Reviewer: Young Lee
Review Date: 4 September 2013
IETF LC End Date:
Intended Status: Standard Track

This document is basically ready for publication, but has some minor issues and nits that should be considered prior to publication.

This document is clearly written and easy to understand, but there are a few places that can be improved. The document title refers this extension as GMPLS Signaling Extensions for "the evolving G.709 OTN control" which may be referred to as "G709v3" in the document to be aligned with the draft name (draft-ietf-ccamp-gmpls-singaling-g709v3).

Major Issues:
No major issues found.

Minor Issues:
Section 3: When referring that VCAT of OPU0/OPU2e/OPU4/OPUflex is not supported by [G709-2012], please add some comment for the readers if this document or other document deals with such extension or that work remains to be worked out in the future. It was not clear why you mentioned of this VCAT issue.

[Fatai] Your comment has been addressed in Section 6.3 in detail way.

Section 4: The clause "via 1.25G TS granularity, 2.5G TS granularity or any one of them (i.e., TS granularity Auto-Negotiation is enabled)" is a bit confusing.

[Fatai]Agree.  I think we can use "ODU-any defined below" to replace "any one of them (i.e., TS granularity Auto-Negotiation is enabled)".

Section 5: The first paragraph can be clearer by associating the objects mentioned with the Path or Resv Message. Please consider to change to: "The traffic Parameters for OTN-TDM capable Switching Type are carried in the OTN-TDM Sender_TSPEC object in the Path Message and the OTN-FLOWSPEC object in the Resv Message."

[Fatai]Agree and accept.

Section 6.2: "In such case" is not clear. Is that meant: "When the TPN was not assigned by the ingress node"?

[Fatai] No, but your comment makes sense. I think we can use "When the TPN is assigned by the ingress node" to replace "In this case".

Section 8, the fourth bullet mentioned of "Ingress" nodes may select the procedure either from RFC4328 or this document. How about the egress nodes? Is it assumed to follow what the ingress has chosen? (Just a clarification question)

[Fatai] There is nothing with egress nodes. There is this bullet because the ingress nodes have chance to select the procedure (either from RFC4328 or this document).


Section 3, when the term "Tributary Slot" is first used (i.e,. A new Tributary Slot granularity (i.e., 1.25Gbps) is also described...), please add the abbreviation.

Section 3
s/legacy interfaces/the legacy interfaces/

Section 4

s/[RFC4328] extends/[RFC4328] extended/

Section 5: Spell NVC.

Section 5.2: For Table 2, align the column dividers

Section 5.2

s/MUST equal to/MUST equal/ or /MUST be equal to/

Section 6.2: delete "out" before "outgoing" in the first sentence of the third paragraph.

Section 6.2: s/accordingly to/according to/ (6th paragraph)