Subject: Re: [CCAMP] OPSDIR review of draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

From: "Zhangxian (Xian)" <[email-masked]>
Date: Fri, 13 Nov 2015 09:39:02 +0000

Hi, Tina,

Thank you for your comments.

Please see my reply inline:

From: Tina TSOU [mailto:[email-masked]]
Sent: 2015年11月13日 15:19
To: [email-masked]; [email-masked]
Subject: OPSDIR review of draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

Dear all,

I have reviewed this document as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the operation area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

** Technical **

* Abstract:

I think the abstract should note the new ctypes that are specified in this document, and what these c-types are used for.

[Xian]: I do not see such a need since the two object class types are just part of the RSVP-TE extensions specified in this draft to support flexi-grid control.

* Section 4.1:

This section should clearly state that m should be interpreted as an unsigned integer.

* Section 4.1:

This section should clearly state that m should be interpreted as an unsigned integer.
[Xian]:  Are these two identical comments? Assume your comments are duplicated, as you probably might notice, earlier in the draft (section 3.2) it is specified that “where m is a positive integer.”, so I think it is sufficient. Do you still see the need to amend in Section 4.1?

* Section 5.1, page 8:

>    IANA is requested to assign the same value for TBD1 and TBD2, and a

>    value of 8 is suggested.

Why do you suggest the value "8"?

[Xian] These values are tied up with a specific technology and last c-type value 7 is used to denote OTN-TDM (see http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml#rsvp-parameters-13) . At the moment, AFAIK, flexi-grid is the only one under discussion. So, we suggest to this value 8 just to follow up. But as you see it is purely a suggestion and up to IANA to modify.

** Editorial **

* Abstract:

>    This memo describes the extensions to the Resource reserVation

>    Protocol Traffic Engineering (RSVP-TE) signaling protocol to support

>    Label Switched Paths (LSPs) in a GMPLS-controlled network that

>    includes devices using the flexible optical grid.

s/Resource/ReSource/.

[Xian]: Ack with you comment. But it should be s/reserVation/reSerVation according to RFC2205.

Cheers,

Xian

Thank you,
Tina

---

From: Tina TSOU <[email-masked]>
Date: Mon, 16 Nov 2015 08:10:08 +0000

Dear Xian,

Thank you for your prompt reply.
Please see my response in-line....

From: Zhangxian (Xian)
Sent: Friday, November 13, 2015 5:39 PM
To: Tina TSOU; [email-masked]; [email-masked]
Cc: CCAMP ([email-masked])
Subject: RE: OPSDIR review of draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

Hi, Tina,

From: Tina TSOU [mailto:[email-masked]]
Sent: 2015年11月13日 15:19
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: OPSDIR review of draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

Dear all,

** Technical **

* Abstract:

[TT] Could you please elaborate what you mean?

* Section 4.1:

* Section 4.1:

This section should clearly state that m should be interpreted as an unsigned integer.
[Xian]:  Are these two identical comments?

[TT] Yes, my bad.

Assume your comments are duplicated, as you probably might notice, earlier in the draft (section 3.2) it is specified that “where m is a positive integer.”, so I think it is sufficient. Do you still see the need to amend in Section 4.1?

[TT] Yes. It is section 4.1 the normative one. The other one is prose.

[TT] It is the first time that I see this sort of suggestion in this context.

But.. fair enough.

** Editorial **

s/Resource/ReSource/.

[TT] Yup.

Cheers,

Xian

Thank you,
Tina

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 16 Nov 2015 09:39:08 +0000

Hi, Tina,

The two remaining open points and my reply below:

<snip>

>[TT] Could you please elaborate what you mean?

[Xian] I meant, in abstract, we do not specify the details of the protocol extensions, as least for those RFCs produced in CCAMP WG (for example, RFC7139). The reason behind, I reckon, is because the protocol extensions are more than merely c-types.  Am I clearer?

<snip>

>Assume your comments are duplicated, as you probably might notice, earlier in the draft (section 3.2) it is specified that “where m is a positive integer.”, so I think it is sufficient. Do you still see the need to amend in >Section 4.1?

>[TT] Yes. It is section 4.1 the normative one. The other one is prose.

[Xian]: fair enough;  I will add “m is a positive integer” in Section 4.1.

Cheers,
Xian

From: Tina TSOU
Sent: 2015年11月16日 16:10
To: Zhangxian (Xian); [email-masked]; [email-masked]
Cc: CCAMP ([email-masked])
Subject: RE: OPSDIR review of draft-ietf-ccamp-flexible-grid-rsvp-te-ext-03

Dear Xian,

From: Zhangxian (Xian)

Hi, Tina,

Dear all,

** Technical **

* Abstract:

* Section 4.1:

* Section 4.1:

[TT] Yes, my bad.

But.. fair enough.

** Editorial **

s/Resource/ReSource/.

[TT] Yup.

Cheers,

Xian

Thank you,
Tina