Hi Dale: I have addressed your comments and uploaded a new version (v14) of the draft today. All the editors for this draft have reviewed the latest set of changes and are OK with these changes. There a couple of points I wanted to mention: 1) I have added some text to clarify that the reader is assumed to have a background in OTN networks, how GMPLS is applied to these networks etc. 2) I have fixed a few definitions to make things clear. 3) You had a suggestion about moving the client mapping figure (Figure 3 in the latest version) to an earlier location in the document. We have not made this change since this involves a lot more than just moving the figure to an earlier point. This requires changing a fair bit of text to make sure that the document reads well. 4) I have added some text in the client mapping section to explain the use of terms like "ODUj", "ODUk" in Figure 3. 5) I had responded to your question about G.709 limiting the range of TPN values for OTUCn links. In my response, I had indicated that this text was just to answer your question -- and that we would not like to include any reasons for limiting the range of TPN values in this document. For these matters, we feel that we should just refer to G.709. Please let us know if you are OK with the updates we have done. Regards, radha -----Original Message----- From: Radhakrishna Valiveti <rvaliveti@xxxxxxxxxxxx> Sent: Friday, October 7, 2022 7:20 PM To: Dale Worley <worley@xxxxxxxxxxx>; gen-art@xxxxxxxx Cc: ccamp@xxxxxxxx; draft-ietf-ccamp-gmpls-otn-b100g-applicability.all@xxxxxxxx; last-call@xxxxxxxx Subject: RE: Genart last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-12 Hi Dale: Thanks a lot for your review & comments. I have responded to some of your comments inline. We will need to have a discussion among the authors & decide the edits to address other comments. Regards, Radha -----Original Message----- From: Dale Worley via Datatracker <noreply@xxxxxxxx> Sent: Thursday, October 6, 2022 7:08 PM To: gen-art@xxxxxxxx Cc: ccamp@xxxxxxxx; draft-ietf-ccamp-gmpls-otn-b100g-applicability.all@xxxxxxxx; last-call@xxxxxxxx Subject: Genart last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-12 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Reviewer: Dale Worley Review result: Ready with Nits 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 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf .org%2Ftrac%2Fgen%2Fwiki%2FGenArtfaq&data=05%7C01%7Crvaliveti%40infinera .com%7Cfcc05a4664744df652be08daa808b19d%7C285643de5f5b4b03a1530ae2dc8aaf77%7 C1%7C0%7C638007052573395799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PSqNHca 8NHvnZq%2Bk3suyG1mJ4cBMElw0zsguCPqetfU%3D&reserved=0>. 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. ============== [Radha] The document does assume that the readers are familiar with OTN, GMPLS and how it is used in OTN networks. We can state this assumption early on the document -- so that the reader is aware that the document will not provide all the required background, and that it only talks about the extensions required to support OTU signals with capacities larger than 100G. As such, rather than expand on the background information, I would prefer to point the reader to existing ITU-T recommendations, and IETF RFCs. I believe we have included all the important references -- but will surely go through the list and expand it to include other docs which may be helpful. ============== 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+. ============== [Radha] Yes -- as you point out, the multiplier to derive the ODU rate is 239/237. We never implied that it was an *integral* multiple of the client bit rate. In any case, I will be happy to clarify the actual multiplier that ITU has standardized. ============== 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. ============== [Radha] The restriction on the TPN range is from G.709 itself. The reduction in the TPN space is to help with optimizing the designs of the OTN framer/mapper ASICs that handle large number of ODU connections. This reduction in TPN space covers the situation in which all the LO-ODUs have rates greater than or equal to 10G. The link will be heavily underutilized if someone insists on carrying only 5G LO-ODUs over B100G links. It is also likely that these B100G links will be used to carry services which have been aggregated by the first stage of multiplexing -- in which case the reduced TPN space is much less of an issue. This reason doesn't appear in G.709 itself and I would not like to include this reason in our document. I am including this response only because you had a question. ============== 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. ============== [Radha] If you look at G.709, an OTUCn is the result of interleaving n synchronous OTUC signals. An OTUC1 is a completely self-contained signal -- it is not a slice of a higher rate OTUCn signal. G.709 follows this convention -- and I would like to stick to it. ============== 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. ============== [Radha] I will discuss this matter with the authors and decide if it helps to move it an earlier point in the document. ============== 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. ============== [Radha] Agree -- We can do that. ============== * 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. ============== [Radha] The ODUC instances are synchronous, and interleaved. We cannot omit the qualifier that they are synchronous members of a collection. I would add the detail that they are interleaved as well. ============== * 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? ============== [Radha] It is a term defined by ITU. See G.709-2020:6.1.1. ============== * 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". ============== [Radha] M is less than 20*n. I agree that the sentence "When M=20*n .... " causes confusion. We would like to rule out using the nomenclature for the case in which all the tributary slots are present -- in which case the OTUCn name is sufficient -- and we don't need it to be known by another name. We will rephrase the last sentence to make the intent clear. ============== * 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. ============== [Radha] I will go through the definitions section and add any missing terms. MSI is useful in the GMPLS context since this attribute signals the composition of the ODUCn signal -- and is used to detect misconnections. If we don't refer to this aspect, we could add some reference to this field. ============== What are "digital section", "multiplex section", and "regenerator section"? ============== [Radha] These are standard terms which ITU-T has been using since the SDH days. We can add a reference -- if required. ============== 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. ============== [Radha] Yes -- I realize the terms ODUj, ODUk cause some confusion. In general, they merely are different indices that signify the rate of the ODUs. That is, "j" and "k" can be viewed as arbitrary indices. Traditionally the choice of the index becomes important when we refer to a single stage multiplexing of Low-order-ODUs (illustrated as ODUj) into High-Order-ODUs (illustrated as ODUk). The deepest ODU stack that Figure 2 allows is ODUj > ODUk > ODUCn. ============== 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". ============== [Radha] Although the FEC columns are shown as part of the OTUk frame, the OTUk FEC is not part of the OTUk OH (see G.709-2020:11.1, Figure 15-3A). But we can add a note that the OTUC doesn't include 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? ============== [Radha] An OTUCn signal extends the ODUCn signal -- as such the combined signal has n instances of OTUC & ODUC overhead. ============== 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. ============== [Radha] The acronym DSP is used to refer to Digital Signal Processor ASICs that implement the modulation/demodulation of digital streams generated by the upstream OTN framers/mapper devices. But we can abstract these components away and only speak about the end results that optical links have a variety of bit rates. ============== 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. ============== [Radha] That is true -- I will see if we need to make it explicit in the document. ============== 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.) ============== [Radha] We can fix this sentence. ============== [END]
<<attachment: smime.p7s>>
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
