Subject: [CCAMP] [Editorial Errata Reported] RFC7139 (3924)

From: RFC Errata System <[email-masked]>
Date: Thu, 20 Mar 2014 20:05:15 -0700 (PDT)

The following errata report has been submitted for RFC7139,
"GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7139&eid=3924

--------------------------------------
Type: Editorial
Reported by: Fatai Zhang <[email-masked]>

Section: 11

Original Text
-------------
5        Unassigned                            [RFC4328]

Corrected Text
--------------
5       Reserved (for G.709)                  [RFC7139]

Notes
-----
(1)Unassigned->Reserved (for G.709)
(2)[RFC4328]->[RFC7139]

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7139 (draft-ietf-ccamp-gmpls-signaling-g709v3-12)
--------------------------------------
Title               : GMPLS Signaling Extensions for Control of Evolving G.709 Optical Transport Networks
Publication Date    : March 2014
Author(s)           : F. Zhang, Ed., G. Zhang, S. Belotti, D. Ceccarelli, K. Pithewan
Category            : PROPOSED STANDARD
Source              : Common Control and Measurement Plane
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 22 Mar 2014 14:38:18 -0000

Hi Fatai,

I'm having trouble understanding the report.

RFC 4328 shows the value 5 as "reserved (for future use)." This is the
equivalent of the IANA tag "Unassigned".

RFC 7139 creates the "OTN Signal Type" registry and includes the value 5 as
Unassigned.

I don't find any other mention of the value 5 in RFC 7139, so I don't understand
how this value is being specially treated. In particular, I don't find any
mention in the table of Signal Types in section 5.

Also, I don't understand the meaning of "Reserved (for G.709)". Does it mean
that the G.709 Recommendation can make a code point allocation? Does it mean
that a future update of RFC 7139 might want to request allocation of this value
for a very specific purpose and so it would be bad to allocate it for something
else?

And lastly, given that these are OTN signal types, and given that OTN is defined
in G.709, why would this value need special reservation treatment "for G.709"?

I'm inclined to reject your Errata Report, but want to give you a chance to
clarify.

Thanks,
Adrian

> -----Original Message-----
> From: RFC Errata System [mailto:[email-masked]]
> Sent: 21 March 2014 03:05
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Editorial Errata Reported] RFC7139 (3924)
> 
> Title               : GMPLS Signaling Extensions for Control of Evolving G.709
Optical
> Transport Networks

---

From: Fatai Zhang <[email-masked]>
Date: Sat, 22 Mar 2014 14:44:28 +0000

Hi Adrian,

That is fine, it is up to you.

I reported this because I got a request from Pearl.

>Fatai, regarding #1, you need to submit an errata to RFC7139 and have the AD verified it before we can update the draft string to the RFC.

Thanks

Fatai

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2014年3月22日 22:38
收件人: Fatai Zhang
抄送: [email-masked]
主题: RE: [Editorial Errata Reported] RFC7139 (3924)

Hi Fatai,

RFC 4328 shows the value 5 as "reserved (for future use)." This is the equivalent of the IANA tag "Unassigned".

RFC 7139 creates the "OTN Signal Type" registry and includes the value 5 as Unassigned.

I don't find any other mention of the value 5 in RFC 7139, so I don't understand how this value is being specially treated. In particular, I don't find any mention in the table of Signal Types in section 5.

Also, I don't understand the meaning of "Reserved (for G.709)". Does it mean that the G.709 Recommendation can make a code point allocation? Does it mean that a future update of RFC 7139 might want to request allocation of this value for a very specific purpose and so it would be bad to allocate it for something else?

And lastly, given that these are OTN signal types, and given that OTN is defined in G.709, why would this value need special reservation treatment "for G.709"?

I'm inclined to reject your Errata Report, but want to give you a chance to clarify.

Thanks,
Adrian

> The following errata report has been submitted for RFC7139, "GMPLS 
> Signaling Extensions for Control of Evolving G.709 Optical Transport 
> Networks".
> 
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
> 
Optical

---

From: Fred Gruman <[email-masked]>
Date: Sun, 23 Mar 2014 08:48:23 -0500

Hi Fatai,

I believe there is an error in RFC 7139 regarding the ITU-T definitions regarding ODUflex(CBR) in Table 1.

Table 1 lists the minimum, nominal and maximum values for the TS.  But the left column is wrong.  Per G.709 (Table 7-7) these values should be listed as ODTUk.ts (ODTU2.ts, ODTU3.ts, ODTU4.ts).  Note that the formulas in this section are written correctly (e.g., refers to ODTUk.ts)

Table 2 for ODUflex(GFP) is correctly referring to ODUk.ts, but I wanted to point out the the values for ODUk.ts are different than ODTUk.ts used for ODUflex(CBR). ODUk.ts is given in G.709 Table 7-8.  You may want to explicitly show the ODUk.ts values to be consistent with ODUflex(CBR), although this update is not absolutely necessary as the text is correct.

Fred

---

From: Lou Berger <[email-masked]>
Date: Sun, 23 Mar 2014 20:50:42 -0400

Fred,

> Table 1 lists the minimum, nominal and maximum values for the TS.  But the left column is wrong.  Per G.709 (Table 7-7) these values should be listed as ODTUk.ts (ODTU2.ts, ODTU3.ts, ODTU4.ts).  No…

^@#%$ -  You are 100% correct.  This once again demonstrates why it is
generally a bad idea to copy text/format/values from other
specifications rather than just referencing them.  Can you file an
errata on this?

> Table 2 for ODUflex(GFP) is correctly referring to ODUk.ts, but I wanted to point out the the values for ODUk.ts are different than ODTUk.ts used for ODUflex(CBR). ODUk.ts is given in G.709 Table 7…
If you really want to see this changed, I suggest that you propose a
specific revision in the errata.

Thank you!
Lou

> Fred
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>

---

From: "Gruman, Fred" <[email-masked]>
Date: Mon, 24 Mar 2014 18:57:13 +0000

Hi Fatai,

I'm reviewing the published OTNv3 RFCs to see if I need to update any of the work in OIF to remain aligned with these documents. As part of this review, I noticed the following regarding ODUflex resize (Section 7):

1. ODUflex resize - teardown of original connection

- For bandwidth increase, the PathTear message is used to delete the original connection
- For bandwidth decrease, the ResvErr message is used to delete the original connection

Is this really what we wanted?  If so, can you let me know why different procedures are required for the two cases?  (Or why not PathTear for both cases?)

I don't think that we've traditionally used ResvErr to teardown an LSP in GMPLS. We've used PathTear (or Path D&R followed by PathErr with path-state-removed). ResvErr is confusing to me, at least the specs in RFC 2205 that gets into discussions of blockage states, etc. Is this even appropriate to use ResvErr to tear down a connection, as my reading of RFC 2205 (although I'm not 100% certain on this) is that a ResvErr does not delete the Path or Resv states.

2. ODUflex resize setup with SE style.

Section 7 states: "Note that the SE style MUST be used at the beginning when creating a resizable ODuflex connection". For the bandwidth decreasing section, it states that "For the ingress node, a Path message with SE style SHOULD also be sent for decreasing the ODUflex bandwidth".  I would think that the "SHOULD" should be changed to "MUST".

Per RFC 2205 (Section 1.3), it is not possible to merge flowspecs when LSPs are signaled with different styles.  I think it would not be legal to have two LSPs with different signaling styles to share the same resource. 

I apologize for getting this question in now. I had thought I had kept up with the changes within the draft but I missed these details.

Lou, once these discussions are complete, I'll submit an errata to cover my issues.

Thanks, 
Fred

---

From: Fatai Zhang <[email-masked]>
Date: Tue, 25 Mar 2014 11:26:58 +0000

Hi Fred,

I think you are right because of the typos after I checked RFC7139 and my memory, since "PathTear" and "MUST" should be used consistently for these two cases.

Thanks

Fatai

-----邮件原件-----
发件人: Gruman, Fred [mailto:[email-masked]] 
发送时间: 2014年3月25日 2:57
收件人: Lou Berger; Fatai Zhang
抄送: [email-masked]
主题: ODUflex resize question in RFC7139 (3924)

Hi Fatai,

Thanks, 
Fred