Re: [auth48] AUTH48: RFC-to-be 9376 <draft-ietf-ccamp-gmpls-otn-b100g-applicability-15> for your review

[[e-mail]]

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 <[e-mail]>, 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: [e-mail] <[e-mail]>
To: 王其磊10101413;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
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, [e-mail] 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
 
  *  [e-mail] (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).
 
  *  [e-mail], 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,  
       [e-mail] 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