I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ccamp-gmpls-otn-b100g-applicability-12 Reviewer: Dale R. Worley Review Date: 2022-10-06 IETF LC End Date: 2022-10-06 IESG Telechat date: [not known] Summary: This draft is essentially ready for publication if the target audience is people who are familiar with optical transport networking, GMPLS, and how GMPLS is used to manage OTN. Otherwise, the provided background information needs to be expanded. I was left with uncertainty as to the intended audience of this document. The Abstract reads This document examines the applicability of using existing GMPLS routing and signalling mechanisms to set up Optical Data Unit-k (ODUk) Label Switched Paths (LSPs) over Optical Data Unit-Cn (ODUCn) links as defined in the 2020 version of G.709. The document implicitly decides that GMPLS is applicable to ODUCn links, and provides certain details of how GMPLS management of early versions of G.709 optical networking would be extended to support ODUCn links. To a considerable degree, the document assumes the reader is familiar with Optical Transport Networking, GMPLS, and how GMPLS is used in an OTN context. It does give a significant amount of information about ODUCn networking, but despite that I know a considerable amount about non-optical networking, I found that part hard going. Very little background is given about GMPLS. The authors need to decide who the target audience is, and expand on the background information if the target audience can't be assumed to know it already. The applicability assessment itself consists of only 3 pages, and comparing to RFC 7139 (which I skimmed), I found nothing missing. Indeed, the entirety seems to be noting that the OTN-TDM Switching Type Generalized Label in RFC 7139 can be widened in the obvious way to support ODUCn transports. There are two minor points which I found very irritating and request the authors to fix even if they target a narrow audience: 1. The "fixed multiple" mentioned here: * ODUflex: Optical Data Unit - flexible rate. An ODUflex has the same frame structure as a "generic" ODU, but with rate that is a fixed multiple of the bitrate of the client signal it encapsulates. Naively, I assume that a "fixed multiple" is "an integer multiple greater than 1". However, the multiple is fixed by OTN as 239/237, which is not integral and is only slightly larger than 1, viz. 1.00843+. 2. TPNs are limited to half the number of TDM slots in the transport signal: The range of tributary port number (TPN) is 10*n instead of 20*n [...] Could some explanation be provided of why this is so? Naively this appears to be an arbitrary constriction of the number of TPNs that can be used for a link. The remainder of this review regards how to clarify the exposition of OTUCn networking for readers unfamiliar with OTN. I have no recommendation how to provide an exposition of GMPLS. 1. Introduction This document focuses on the use of existing GMPLS mechanisms to set up ODUk (e.g., ODUflex) Label Switched Paths (LSPs) over ODUCn links, independently from how these links have been set up. It seems to be understood but clearly not stated that each ODUCn link is contained within one OTUCn link, and similarly that the "payload space" in the ODUCn framing/data structure is called/considered an OPUCn. Thus discussions of the three things are highly parallel. Generally, each OTUCn is an interleaving of n OTUC1s, each contained ODUCn is an interleaving/multiplexing of n OTUD1s, and each contained OPUCn is an interleaving of n OPUC1s. But this is only partially stated. Figure 2 (at the end of section 3) provided an extremely helpful picture of how the various protocols are layered. It should be early in the introduction or terminology. 2. OTN terminology used in this document * LSP: Label Switched Path. This document mainly focuses on the label switched paths which traverse Time-Division Multiplex Capable (TDM) interfaces defined in [RFC3471]. This sentence is not a part of the definition of LSP but is rather a limitation on the applicability of the whole document, and should be promoted to a prominent position in the document. * ODUCn: Optical Data Unit-Cn; Cn indicates the bit rate of approximately n*100G. This frame structure consists of "n" synchronous instances of the ODUC signal, each of which has the format defined in Figure 12-1 of [ITU-T_G709_2020]. I think you want the phrase "interleaved instances" rather than "synchronous instances". The latter says that the instances correspond in time, but does not say that all of their contents are traveling on a single data path. * OTUCn: Fully standardized Optical Transport Unit-Cn. This frame structure is realized by extending the ODUCn signal with the OTU layer overhead. Does "fully standardized" mean anything here? Given that this is "fully standardized", should a reference be given? * OTUCn-M: [...] Specifically, the payload area consists of M 5 Gbit/s tributary slots (where M is less than 20*n). When M=20*n, this signal is identical to the full OTUCn signal, and there is no need for the "-M" suffix in the entity name. You need to get your terminology aligned here. Do you mean "M is less than 20*n" or "M is less than or equal to 20*n"? Because saying "When M=20*n ..." implies that M = 20*n is an acceptable case of OTUCn-M, a case which is also equivalent to OTUCn. But if you never want to include that case in the term "OUTCn-M", then the last sentence must use the subjunctive mood and start "Were M=20*n, this signal would be identical to the full OTUCn signal, which is designated OTUCn instead". * PSI: OPU Payload Structure Indicator. This is a 256-byte signal that describes the composition of the OPU signal. This field is a concatenation of the Payload type (PT) and the Multiplex Structure Indicator (MSI) defined below. There is no definition of "OPU" or "Payload type". Indeed, "PSI" is not used in the document. The plain terms "OTUC", "ODUC", and "OPUC" are used throughout the document but not defined. "OTU" and "ODU" aren't defined in this section, but they are in section 1. What are "digital section", "multiplex section", and "regenerator section"? There is some mystery regarding "ODUj" and "ODUk". My reflex is to assume that these are the same thing, just using different letters as placeholders for the index. But Figure 2 and some of the wording suggests that "ODUj" and "ODUk" are conventionally used to represent different sets of "ODUx" signals. Detailed descriptions of these terms can be found in [ITU-T_G709_2020]. Since this document really depends on G.709, this should probably be at the start of section 2 rather than the end. 3. Overview of the OTUCn/ODUCn in G.709 * Each of the OTUC instances has the same overhead as the standard OTUk signal in [ITU-T_G709_2020]. Rather, given the previous point, "the same overhead as the standard OTUk signal, except without the FEC columns". The combined signal OTUCn has n instances of OTUC overhead, ODUC overhead. This appears to be an editing error. Should the final two words be omitted? OTUCn interfaces can be categorized as follows, based on the type of peer network element: Are this and the following paragraphs significant in the scope of this document? 3.1.1. OTUCn-M Modern DSPs support a variety of bit rates per wavelength, depending on the reach requirements for the optical path. What is a DSP in this context? I'm guessing that "optical interface" works as well here. 3.3. Tributary Slot Granularity The range of tributary port number (TPN) is 10*n instead of 20*n, which restricts the maximum client signals that could be carried over one single ODUC1. Specifically, it restricts it to 10 client signals. 4.3. Implications and Applicability for GMPLS Routing Since the ODUCn link is the lowest layer of the ODU multiplexing hierarchy, there is no need to explicitly define a new value to represent the ODUCn signal type in the OSPF-TE routing protocol. Figure 2 shows OTUCn as a layer lower than ODUCn, so this sentence should be modified. (I suspect that the ODUCn's are intrinsically in 1-1 correspondence with the OTUCn's, and so no signaling is needed regarding that relationship.) [END]