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

[Radhakrishna Valiveti <[e-mail]>]

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 <[e-mail]> 
Sent: Friday, October 7, 2022 7:20 PM
To: Dale Worley <[e-mail]>; [e-mail]
Cc: [e-mail];
[e-mail];
[e-mail]
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 <[e-mail]> 
Sent: Thursday, October 6, 2022 7:08 PM
To: [e-mail]
Cc: [e-mail];
[e-mail];
[e-mail]
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&amp;data=05%7C01%7Crvaliveti%40infinera
.com%7Cfcc05a4664744df652be08daa808b19d%7C285643de5f5b4b03a1530ae2dc8aaf77%7
C1%7C0%7C638007052573395799%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=PSqNHca
8NHvnZq%2Bk3suyG1mJ4cBMElw0zsguCPqetfU%3D&amp;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]