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

From: Leeyoung <[email-masked]>
Date: Wed, 4 Sep 2013 16:27:11 +0000

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

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

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

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.

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

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

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)

Nits:

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)

Thanks.

Young

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 5 Sep 2013 08:02:40 +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

Fatai

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

Hello,

Summary:

Comments:

Major Issues:
No major issues found.

Minor Issues:

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

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

[Fatai]Agree and accept.

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

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

Nits:

Section 3

Section 4

Section 5: Spell NVC.

Section 5.2

Thanks.

Young

---

From: Leeyoung <[email-masked]>
Date: Thu, 5 Sep 2013 15:15:33 +0000

Hi Fatai,

Thanks for your quick resolution. I have no further issue pending after your proposed changes.

Regards,
Young

From: Fatai Zhang
Sent: Thursday, September 05, 2013 3:03 AM
To: Leeyoung; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt

Hi Young and all,

Best Regards

Fatai

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Leeyoung
Sent: Thursday, September 05, 2013 12:27 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt

Hello,

Summary:

Comments:

Major Issues:
No major issues found.

Minor Issues:

[Fatai]Agree and accept.

Nits:

Section 3

Section 4

Section 5: Spell NVC.

Section 5.2

Thanks.

Young