[Last-Call] Genart last call review of draft-ietf-ccamp-gmpls-otn-b100g-applicability-12

[Dale Worley via Datatracker <[e-mail]>]

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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

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]