Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
wang.qilei@zte.com.cn Fri, 10 March 2023 02:23 UTC
Return-Path: <wang.qilei@zte.com.cn>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6467BC16B5CB; Thu, 9 Mar 2023 18:23:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUoPOTPTMGXP; Thu, 9 Mar 2023 18:23:18 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7925FC16B5B4; Thu, 9 Mar 2023 18:23:15 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4PXqbP3B9vz6FK2Y; Fri, 10 Mar 2023 10:23:13 +0800 (CST)
Received: from szxlzmapp02.zte.com.cn ([10.5.231.79]) by mse-fl1.zte.com.cn with SMTP id 32A2N4Io031124; Fri, 10 Mar 2023 10:23:04 +0800 (+08) (envelope-from wang.qilei@zte.com.cn)
Received: from mapi (szxlzmapp05[null]) by mapi (Zmail) with MAPI id mid16; Fri, 10 Mar 2023 10:23:05 +0800 (CST)
Date: Fri, 10 Mar 2023 10:23:05 +0800
X-Zmail-TransId: 2b07640a9489ffffffffd1fb4e0f
X-Mailer: Zmail v1.0
Message-ID: <202303101023057853856@zte.com.cn>
Mime-Version: 1.0
From: wang.qilei@zte.com.cn
To: rfc-editor@rfc-editor.org, rvaliveti@infinera.com, zhenghaomian@huawei.com, huubatwork@gmail.com, sergio.belotti@nokia.com
Cc: rfc-editor@rfc-editor.org, ccamp-ads@ietf.org, ccamp-chairs@ietf.org, adrian@olddog.co.uk, jgs@juniper.net, auth48archive@rfc-editor.org, zhangfatai@huawei.com, adrian@olddog.co.uk, andrew-ietf@liquid.tech
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 32A2N4Io031124
X-Fangmail-Gw-Spam-Type: 0
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 640A9491.000/4PXqbP3B9vz6FK2Y
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/QCk3_x3i2hPoRR1gdyTSgVUCbQ4>
Subject: Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Mar 2023 02:23:23 -0000
Resend,,,, since I received a number of undelivered email notification for Adrian, Fatai and Andrew. ========================================================== Dear RFC editor, First, I approve this RFC for publication. Second, replies to the comments could be seen below, which are from Huub and myself. The numbering below is consistent with the comments proposed by the RFC editor. 1), Title OLD:Applicability of GMPLS for Beyond 100G Optical Transport Network NEW: Applicability of GMPLS for beyond 100G Optical Transport Network Qilei: Usage of "Optical Transport Networks" is not supported since G.709 use "Optical Transport Network", network instead of networks. Fine with other changes proposed by the RFC editor. 2), Qilei: No need to include the "100G" and "Optical Transport Network" in the abstract, since "100G" and "Optical Transport Network" could be inferred. 3), Qilei: I got feedback from Huub, he was OK for: a) H. van Helvoort and b) Hai Gaoming BV. 4), "B100G OTN" 5), Section 1 OLD: Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts with [ITU-T_G709_2020] by first presenting an overview of the OTUCn and ODUCn signals, and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links. NEW: Since [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document first presents an overview of the OTUCn and ODUCn signals in [ITU-T_G709_2020], and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links. 6), Qilei: Yes 7), Section 2 OLD: FlexO: Flexible OTN information structure. This information structure is usually with a specific bit rate and frame format, consisting of overhead and payload, which is used as a group for the transport of an OTUCn signal. NEW: FlexO: Flexible OTN information structure. This information structure usually has a specific bitrate and frame format that consists of overhead and payload, which are used as a group for the transport of an OTUCn signal. 8), Section 2 OLD: ITU-T defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc. ... NEW: [ITU-T_G709_2020] defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc. ... [ITU-T_G709_2020] supports the notion of a reduced rate OTUCn signal, termed the OTUCn-M. 9), Qilei: OK with the update proposed by RFC editor. 10), Qilei: yes, it should be Figure 11-4. 11), Section 2 OLD: Specifically, the payload area consists of M 5 Gbit/s tributary slots - where M is less than 20*n, which is the number of tributary slots in the OTUCn signal.NEW: Specifically, the payload area consists of M tributary slots (each 5 Gbit/s), where M is less than 20*n, which is the number of tributary slots in the OTUCn signal.Section 4.2 OLD: One ODUC10 has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4.NEW: One ODUC10 has 200 slots (each 5 Gbit/s), and twenty of them are allocated to the ODU4. Section 3.4: OLD: As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs). NEW: As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) (each 5 Gbit/s). 12), Qilei: OK Section 2: OLD: PSI: OPU Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. NEW: PSI: Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. 13), Qilei: OK Section 2 OLD: Detailed descriptions of these terms can be found in [ITU-T_G709_2020]. NEW: Detailed descriptions for some of these terms can be found in [ITU-T_G709_2020]. 14), Qilei: OK. Section 3.1: OLD: * The OTUCn signals can be viewed as being formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n). NEW: * The OTUCn signals are formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n). 15), Section 3.1.1 OLD: If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100G, it is possible to "crunch" the OTUCn not to transmit the unused tributary slots. NEW: If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100G, it is possible to "crunch" the OTUCn and thus the unused tributary slots are not transmitted. 16), Section 3.2 OLD: The ODUC frames have the same structure as a standard ODU in the sense that it has the same overhead and payload areas, but has a higher rate since its payload area can embed an ODU4 signal. NEW: The ODUC frames have the same structure as a standard ODU in the sense that the frames have the same overhead and payload areas but have a higher rate since their payload area can embed an ODU4 signal. 17), Section 3.4 OLD: * The TS availability bit indicates if the tributary slot is available or unavailable * The TS occupation bit indicates if the tributary slot is allocated or unallocated * The tributary port number (14 bits) of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n. NEW: * The TS availability bit indicates if the tributary slot is available or unavailable. * The TS occupation bit indicates if the tributary slot is allocated or unallocated. * The tributary port number (14 bits) indicates the port number of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n. 18), Qilei: the figure number is correct. No modification is needed. 19), Section 4.2, 4.3 OLD: 4. GMPLS Implications and Applicability 4.1. TE-Link Representation 4.2. Implications and Applicability for GMPLS Signalling 4.3. Implications and Applicability for GMPLS Routing NEW: 4. GMPLS Implications and Applicability 4.1. TE-Link Representation 4.2. GMPLS Signaling 4.3. GMPLS Routing 20), Figure 4, Figure 5 OLD: Figure 4: OTUCn TE-Links Figure 5: Multiple-hop ODUCn TE-Link NEW: Figure 4: One-Hop OTUCn TE-Link Figure 5: Multi-Hop ODUCn TE-Link 21), Section 4.2, OLD: As the resource on the ODUCn link which can be seen by the client ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. NEW: As the resource on the ODUCn link that can be seen by the ODUk/ODUflex client signal is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex client signal over ODUCn link. 22), Section 4.2 OLD: Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. NEW: Since the TPN defined in [ITU-T_G709_2020] (where it is referred to as "tributary port #") for an ODUCn link has 14 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. 23), Section 4.2, OLD: With this label encoding, only 20 out of the 200 bits mask are non- zero, and is very inefficient. NEW: With this label encoding, only 20 out of the 200 bits mask are non- zero, which is very inefficient. 24), Qilei: Please be noted that some updates to the texts in section 4.3 were agreed by the authors, chairs of CCAMP and AD. CCAMP chair sent one email to <rfc-editor@rfc-editor.org>, explaning the cause and effect of this updates. Section 4.3 OLD: For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed. Because once an ODUCn link is up, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the multiplexing hierarchy on this link. Since the ODUCn link is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, and there is a 1:1 correspondence with the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol. The OSPF-TE extension defined in section 4 of [RFC7138] can be reused to advertise the resource information on the ODUCn link to help finish the setup of ODUk/ODUflex. NEW: For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed. The ODUCn link, which is the lowest layer of the ODU multiplexing hierarchy involving multiple ODU layers, is assumed to have been already configured when GMPLS is used to set up ODUk over ODUCn, therefore the resources that need to be advertised are the resources that are exposed by this ODUCn link and the ODUk multiplexing hierarchy on it. The 5Gbit/s OPUCn time slots do not need to be advertised, while the 1.25Gbit/s and 2.5Gbit/s OPUk time slots need to be advertised using the mechanisms already defined in [RFC7138]. Since there is a 1:1 correspondence between the ODUCn and the OTUCn signal, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol. 25), Qilei: OK OLD: [ITU-T_G709_2020] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 06/2020", June 2020. [ITU-T_G709_2012] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 02/2012", February 2012. [ITU-T_G709_2016] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 07/2016", July 2016. NEW: [ITU-T_G709_2020] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2020. [ITU-T_G709_2012] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, February 2012. [ITU-T_G709_2016] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2016. 26), Qilei: a), use "n * 100Gbit/s". b), it is clear, no change c), no need to explain GE 27), Qilei: the following terminologies are suggested: a), TE link section-layer multi-hop b), ODUflex bitrate c), please remove the "network" following the "OTN" d), "k" and "j" stand for the high order and lower order of ODU, which are known to people who are familar with OTN, suggest no change to the draft. e), correct f), Generalized Payload Identifier, in RFC3471. 28), Qilei: done Thank you Qilei Original From: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org> To: 王其磊10101413;rvaliveti@infinera.com <rvaliveti@infinera.com>;zhenghaomian@huawei.com <zhenghaomian@huawei.com>;huubatwork@gmail.com <huubatwork@gmail.com>;sergio.belotti@nokia.com <sergio.belotti@nokia.com>; Cc: rfc-editor@rfc-editor.org <rfc-editor@rfc-editor.org>;ccamp-ads@ietf.org <ccamp-ads@ietf.org>;ccamp-chairs@ietf.org <ccamp-chairs@ietf.org>;adrian@olddog.co.uk <adrian@olddog.co.uk>;jgs@juniper.net <jgs@juniper.net>;auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>; Date: 2023年02月28日 14:40 Subject: Re: AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. 1) <!-- [rfced] Please review "for Beyond 100G Optical Transport Network" in the document title. Would any updates be helpful to improve clarity? Original: Applicability of GMPLS for Beyond 100G Optical Transport Network Perhaps: Applicability of GMPLS for beyond 100G Optical Transport Networks Or: Applicability of GMPLS for Optical Transport Networks with Link Capacity above 100G In addition, please review the short title (which appears in the running header at the top of each page in the PDF output). For now, we have updated as shown below to align better with the document title, but changes may be needed depending on the response to the question above about the document title. Original: B100G Extensions Perhaps: Applicability of GMPLS beyond 100G OTN --> 2) <!-- [rfced] We note that the document title includes "100G" and "Optical Transport Network", but these terms are not included in the abstract. Let us know if any updates are needed. --> 3) <!-- [rfced] Huub, we made the following updates in your author listing. Please let us know any concerns. a) We updated your surname in the document header from "H. Helvoort" to "H. van Helvoort". b) We updated "Hai Gaoming B.V" to "Hai Gaoming BV" (no period) per the affiliation listed in RFCs 8234, 8227, and 7771. Please let us know if "Hai Gaoming B.V." (two periods) is better. --> 4) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 5) <!-- [rfced] What does "this document starts with [ITU-T_G709_2020]" mean here? Will it be clear to readers? Original: Because [ITU-T_G709_2020] does not introduce any new features to OTUCn and ODUCn compared to [ITU-T_G709_2016], this document starts with [ITU-T_G709_2020] by first presenting an overview of the OTUCn and ODUCn signals, and then analyzing how the current GMPLS routing and signalling mechanisms can be utilized to set up ODUk (e.g., ODUflex) LSPs over ODUCn links. --> 6) <!-- [rfced] Would you like to put the terms listed and defined in Section 2 in alphabetical order? --> 7) <!-- [rfced] Please review "is usually with a specific bit rate and frame format". Should this read "usually has a specific bit rate and frame format" (or something similar) for clarity? Also, what does the "which is.." clause refer to ("bit rate and frame format" or "overhead and payload")? Will this be clear to readers? Original: FlexO: Flexible OTN information structure. This information structure is usually with a specific bit rate and frame format, consisting of overhead and payload, which is used as a group for the transport of an OTUCn signal. Perhaps: FlexO: Flexible OTN information structure. This information structure usually has a specific bitrate and frame format (consisting of overhead and payload), which are used as a group for the transport of an OTUCn signal. Or: FlexO: Flexible OTN information structure. This information structure usually has a specific bitrate and frame format that consists of overhead and payload, which are used as a group for the transport of an OTUCn signal. --> 8) <!-- [rfced] In these sentences, would it be helpful to specify which ITU-T document "defines" and "supports"? Or is the current text sufficient? Original: ITU-T defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc. ... ITU-T supports the notion of a reduced rate OTUCn signal, termed the OTUCn-M. --> 9) <!-- [rfced] FYI - We removed the space before "-C" in the following definitions to correspond with the closed form used with "-Cn". In addition, we updated these definitions as follows to have a similar structure. Please review and let us know any objections. Original: ODUC: Optical Data Unit -C; this signal has a bandwidth of approximately 100G, and is of a slightly higher bit rate than the fixed rate ODU4 signal. ... OPUC: Optical Payload Unit -C; with a payload of approximately 100G. ... OTUC: Optical Transport Unit -C; with a bandwidth of approximately 100G. Updated: ODUC: Optical Data Unit-C. This signal has a bandwidth of approximately 100G and is of a slightly higher bitrate than the fixed rate ODU4 signal. ... OPUC: Optical Payload Unit-C. This signal has a payload of approximately 100G. ... OTUC: Optical Transport Unit-C. This signal has a bandwidth of approximately 100G. --> 10) <!-- [rfced] Please confirm that "Figure 11-1" is correct here. We ask because Figure 11-1 of [ITU-T_G709_2020] is titled "OTUk frame structure", but this definition is for OTUCn. Note that Figure 11-4 is titled "OTUCn frame structure"; is that the correct figure reference here? Please see https://www.itu.int/rec/T-REC-G.709-202006-I/en. Original: * OTUCn: Fully standardized Optical Transport Unit-Cn. This frame structure is realized by extending the ODUCn signal with the OTU layer overhead. The structure of this signal is illustrated in Figure 11-1 of [ITU-T_G709_2020]. --> 11) <!--[rfced] May these instances of "5 Gbit/s" (immediately preceded by a variable or digits) be rephrased to improve readability? For comparison, Section 3.3 uses the phrase "20*n tributary slots (of 5 Gbit/s capacity)". Original (Section 2): Specifically, the payload area consists of M 5 Gbit/s tributary slots - where M is less than 20*n, which is the number of tributary slots in the OTUCn signal. Perhaps: Specifically, the payload area consists of M tributary slots (each 5 Gbit/s), where M is less than 20*n, which is the number of tributary slots in the OTUCn signal. Original (Section 4.2): One ODUC10 has 200 5 Gbit/s slots, and twenty of them are allocated to the ODU4. Perhaps: One ODUC10 has 200 slots that are each 5 Gbit/s, and twenty of them are allocated to the ODU4. Original (Section 3.4): As mentioned above, the OPUCn signal has 20*n 5 Gbit/s tributary slots (TSs). Perhaps: As mentioned above, the OPUCn signal has 20*n tributary slots (TSs) that are each 5 Gbit/s. --> 12) <!-- [rfced] May we update "OPU Payload Structure Indicator" to simply "Payload Structure Indicator" (no "OPU")? OPU is mentioned in the following sentence. Original: PSI: OPU Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. Perhaps: PSI: Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. --> 13) <!-- [rfced] This sentence appears at the end of Section 2. We note that "LSP" appears in the list of terms in Section 2, but we do not see it in [ITU-T_G709_2020]. Should this sentence be updated accordingly (i.e., "some of these terms")? Original: Detailed descriptions of these terms can be found in [ITU-T_G709_2020]. Perhaps: Detailed descriptions for some of these terms can be found in [ITU-T_G709_2020]. --> 14) <!-- [rfced] Is "can be viewed as being formed" correct? Or would updating to "are formed" work? Original: * The OTUCn signals can be viewed as being formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n). Perhaps: * The OTUCn signals are formed by interleaving n synchronous OTUC signals (which are labeled 1, 2, ..., n). --> 15) <!-- [rfced] Please review "not to transmit". Should this read "and not transmit", "so that it will not transmit", or something similar? Original: If the total rate of the ODUk LSPs planned to be carried over an ODUCn link is smaller than n*100G, it is possible to "crunch" the OTUCn not to transmit the unused tributary slots. --> 16) <!-- [rfced] Will it be clear to readers what "it" refers to here ("frames" or "structure")? Original: The ODUC frames have the same structure as a standard ODU in the sense that it has the same overhead and payload areas, but has a higher rate since its payload area can embed an ODU4 signal. Perhaps: The ODUC frames have the same structure as a standard ODU in the sense that structure has the same overhead and payload areas but has a higher rate since its payload area can embed an ODU4 signal. Or: The ODUC frames have the same structure as a standard ODU in the sense that the frames have the same overhead and payload areas but have a higher rate since their payload area can embed an ODU4 signal. --> 17) <!-- [rfced] The first two bullets are complete sentences, but the third bullet starts with a sentence fragment. How may we update this text so that the list has parallel structure? Original: * The TS availability bit indicates if the tributary slot is available or unavailable * The TS occupation bit indicates if the tributary slot is allocated or unallocated * The tributary port number (14 bits) of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n. Perhaps: * The TS availability bit indicates if the tributary slot is available or unavailable. * The TS occupation bit indicates if the tributary slot is allocated or unallocated. * The tributary port number (14 bits) indicates the port number of the client signal that is being carried in this specific TS. A flexible assignment of tributary port to tributary slots is possible. Numbering of tributary ports is from 1 to 10*n. --> 18) <!--[rfced] Is Figure 3, which is titled "Digital Structure of OTN Interfaces (from Figure 6-1 of [ITU-T_G709_2020]", the correct figure number here? Original: As Figure 3 illustrates, the ODUCn is also a high- order ODU into which other ODUs can be multiplexed; the ODUCn itself cannot be multiplexed into any higher rate ODU signal; it is defined to be a section level signal. --> 19) <!-- [rfced] Please review this section title along with the titles of the subsections. Is it necessary to repeat "Implications and Applicability" in the titles of the subsections? Original: 4. GMPLS Implications and Applicability 4.1. TE-Link Representation 4.2. Implications and Applicability for GMPLS Signalling 4.3. Implications and Applicability for GMPLS Routing Perhaps: 4. GMPLS Implications and Applicability 4.1. TE-Link Representation 4.2. GMPLS Signaling 4.3. GMPLS Routing --> 20) <!-- [rfced] Please review the title of Figure 4. Would updating as shown below be in improvement? The sentence that appears right before the figure states, "Figure 4 below provides an illustration of a one-hop OTUCn TE link." Also, we included the title of Figure 5 below to show a comparison. Original: Figure 4: OTUCn TE-Links Figure 5: Multiple-hop ODUCn TE-Link Perhaps: Figure 4: One-Hop OTUCn TE-Link Figure 5: Multiple-Hop ODUCn TE-Link --> 21) <!-- [rfced] We are having trouble understanding how the text starting with "the label..." connects to the rest of the sentence. Should this be a new sentence? Original: As the resource on the ODUCn link which can be seen by the client ODUk/ODUflex is a set of 5 Gbit/s slots, the label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. Perhaps: As the resource on the ODUCn link that can be seen by the client, ODUk/ODUflex is a set of 5 Gbit/s slots. The label defined in [RFC7139] is able to accommodate the requirement of the setup of ODUk/ODUflex over ODUCn link. --> 22) <!-- [rfced] May this sentence be updated as follows? We ask because the acronym "TPN" does not appear in [ITU-T_G709_2020], though there is one instance of "tributary port number" and many instances of "tributary port #". Original: Since the TPN defined in [ITU-T_G709_2020] for an ODUCn link has 14 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. Perhaps: Since the TPN defined in [ITU-T_G709_2020] (where it is referred to as "tributary port #") for an ODUCn link has 14 bits, while this field in [RFC7139] only has 12 bits, some extension work will eventually be needed. --> 23) <!-- [rfced] Please review "and is very inefficient". Should this read "which is very inefficient"? Original: With this label encoding, only 20 out of the 200 bits mask are non- zero, and is very inefficient. Perhaps: With this label encoding, only 20 out of the 200 bits mask are non- zero, which is very inefficient. --> 24) <!-- [rfced] The text beginning with "Because" is not a complete sentence. Should it be connected to the sentence that precedes it or recast as a complete sentence? Original: For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed. Because, once an ODUCn link is up, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the multiplexing hierarchy on this link. Perhaps (connected to sentence before): For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed, because once an ODUCn link is up, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the multiplexing hierarchy on this link. Or (recast as complete sentence): For routing, it is deemed that no extension to current mechanisms defined in [RFC7138] is needed. Once an ODUCn link is up, the resources that need to be advertised are the resources that are exposed by this ODUCn link and the multiplexing hierarchy on this link. --> 25) <!-- [rfced] FYI - We updated the titles of these reference entries to match the titles in the following URLs. We also updated the month of the 2016 version from July to June. - 2020 version: https://www.itu.int/rec/T-REC-G.709-202006-I/en - 2012 version: https://www.itu.int/rec/T-REC-G.709-201202-S/en - 2016 version: https://www.itu.int/rec/T-REC-G.709-201606-S/en Original: [ITU-T_G709_2020] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 06/2020", June 2020. [ITU-T_G709_2012] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 02/2012", February 2012. [ITU-T_G709_2016] ITU-T, "ITU-T G.709: Optical Transport Network Interfaces; 07/2016", July 2016. Updated: [ITU-T_G709_2020] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2020. [ITU-T_G709_2012] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, February 2012. [ITU-T_G709_2016] ITU-T, "Interfaces for the optical transport network", ITU-T Recommendation G.709, June 2016. --> 26) <!--[rfced] Regarding notation and units a) Typically, this document uses asterisk as the symbol for multiplication, and there's one instance of "x". May "x" be changed to "times" here in order to avoid using two different symbols for multiplication? Original: a nominal rate of n x 100 Gbit/s Perhaps: a nominal rate of n times 100 Gbit/s (For comparison, in Section 2, "n*100G" is used.) b) Both "Gbit/s" and "G" are used for units (e.g., "100 Gbit/s" and "100G") in this document. Would you like to add text that "G" stands for "Gbit/s", or will it be sufficiently clear to the reader? c) Similarly, would you like to add text that "GE" stands for "Gigabit Ethernet"? If so, please provide the text and the location. Section 2: ITU-T defines specific ODUflex containers that are required to transport specific clients such as 50GE, 200GE, 400GE, etc. --> 27) <!-- [rfced] Terminology a) We note inconsistencies in the terms below throughout the text. Should these be uniform? If so, please let us know which form is preferred. TE link vs. TE Link vs. TE-link vs. TE-Link Note: Although RFC 7138 uses "TE-Link", "TE link" is more common in the RFC Series. digital section roles vs. digital section layer role Note: If keeping the latter, we suggest adding a hyphen: "digital section-layer role". multiple-hop vs. multihop Note: The forms "multihop" and "multi-hop" are more common in the RFC Series than "multiple-hop". However, RFC 7138 has two instances of "multiple-hop". b) We note inconsistencies in the term listed below. We chose the form on the right. Please let us know any objections. ODUFlex vs. ODUflex Note: RFCs 7062, 7138, and 7139, as well as [ITU-T_G709_2020] use "ODUflex". bit rate vs. bitrate c) Please review "OTN network" and let us know if any changes are needed. We ask because the expanded form would be "Optical Transport Network network". d) The following terms are mentioned in the text but not defined in Section 2 or elsewhere in the document (though Section 3.5 includes an explanation of "ODUj"). Please review and let us know if/how these should be defined in Section 2 or elsewhere. OTUk (6 instances) OPUk (1 instance) ODUj (5 instances) OPUj (1 instance) e) "FEC" has been expanded as "Forward Error Correction (FEC)" to match [ITU-T_G709_2020]. Please review whether this expansion is accurate. f) How should "G-PID" be expanded in this document? As "Generalized Protocol Identifier"? --> 28) <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> Thank you. RFC Editor/rv/ar On Feb 27, 2023, rfc-editor@rfc-editor.org wrote: *****IMPORTANT***** Updated 2023/02/27 RFC Author(s): -------------- Instructions for Completing AUTH48 Your document has now entered AUTH48. Once it has been reviewed and approved by you and all coauthors, it will be published as an RFC. If an author is no longer available, there are several remedies available as listed in the FAQ (https://www.rfc-editor.org/faq/). You and you coauthors are responsible for engaging other parties (e.g., Contributors or Working Group) as necessary before providing your approval. Planning your review --------------------- Please review the following aspects of your document: * RFC Editor questions Please review and resolve any questions raised by the RFC Editor that have been included in the XML file as comments marked as follows: <!-- [rfced] ... --> These questions will also be sent in a subsequent email. * Changes submitted by coauthors Please ensure that you review any changes submitted by your coauthors. We assume that if you do not speak up that you agree to changes submitted by your coauthors. * Content Please review the full content of the document, as this cannot change once the RFC is published. Please pay particular attention to: - IANA considerations updates (if applicable) - contact information - references * Copyright notices and legends Please review the copyright notice and legends as defined in RFC 5378 and the Trust Legal Provisions (TLP – https://trustee.ietf.org/license-info/). * Semantic markup Please review the markup in the XML file to ensure that elements of content are correctly tagged. For example, ensure that <sourcecode> and <artwork> are set correctly. See details at <https://authors.ietf.org/rfcxml-vocabulary>. * Formatted output Please review the PDF, HTML, and TXT files to ensure that the formatted output, as generated from the markup in the XML file, is reasonable. Please note that the TXT will have formatting limitations compared to the PDF and HTML. Submitting changes ------------------ To submit changes, please reply to this email using ‘REPLY ALL’ as all the parties CCed on this message need to see your changes. The parties include: * your coauthors * rfc-editor@rfc-editor.org (the RPC team) * other document participants, depending on the stream (e.g., IETF Stream participants are your working group chairs, the responsible ADs, and the document shepherd). * auth48archive@rfc-editor.org, which is a new archival mailing list to preserve AUTH48 conversations; it is not an active discussion list: * More info: https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc * The archive itself: https://mailarchive.ietf.org/arch/browse/auth48archive/ * Note: If only absolutely necessary, you may temporarily opt out of the archiving of messages (e.g., to discuss a sensitive matter). If needed, please add a note at the top of the message that you have dropped the address. When the discussion is concluded, auth48archive@rfc-editor.org will be re-added to the CC list and its addition will be noted at the top of the message. You may submit your changes in one of two ways: An update to the provided XML file — OR — An explicit list of changes in this format Section # (or indicate Global) OLD: old text NEW: new text You do not need to reply with both an updated XML file and an explicit list of changes, as either form is sufficient. We will ask a stream manager to review and approve any changes that seem beyond editorial in nature, e.g., addition of new text, deletion of text, and technical changes. Information about stream managers can be found in the FAQ. Editorial changes do not require approval from a stream manager. Approving for publication -------------------------- To approve your RFC for publication, please reply to this email stating that you approve this RFC for publication. Please use ‘REPLY ALL’, as all the parties CCed on this message need to see your approval. Files ----- The files are available here: https://www.rfc-editor.org/authors/rfc9376.xml https://www.rfc-editor.org/authors/rfc9376.html https://www.rfc-editor.org/authors/rfc9376.pdf https://www.rfc-editor.org/authors/rfc9376.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9376-diff.html https://www.rfc-editor.org/authors/rfc9376-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9376-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9376 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9376 (draft-ietf-ccamp-gmpls-otn-b100g-applicability-15) Title : Applicability of GMPLS for Beyond 100G Optical Transport Network Author(s) : Q. Wang, Ed., R. Valiveti, Ed., H. Zheng, Ed., H. Helvoort, S. Belotti WG Chair(s) : Daniele Ceccarelli, Fatai Zhang, Luis M. Contreras Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… rfc-editor
- [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-ccamp… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… wang.qilei
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… wang.qilei
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Rebecca VanRheenen
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… wang.qilei
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Radhakrishna Valiveti
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Rebecca VanRheenen
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Rebecca VanRheenen
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… wang.qilei
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Rebecca VanRheenen
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… wang.qilei
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Sergio Belotti (Nokia)
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Zhenghaomian
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Huub van Helvoort
- Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-c… Rebecca VanRheenen
- [auth48] [AD] Re: AUTH48: RFC-to-be 9376 <draft-i… Rebecca VanRheenen
- Re: [auth48] [AD] AUTH48: RFC-to-be 9376 <draft-i… Rebecca VanRheenen
- Re: [auth48] [AD] AUTH48: RFC-to-be 9376 <draft-i… John Scudder
- Re: [auth48] [AD] AUTH48: RFC-to-be 9376 <draft-i… Rebecca VanRheenen