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

[[e-mail]]

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