Radhakrishna Valiveti <rvaliveti@xxxxxxxxxxxx> writes:
> 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.
Since I am (in concept) a representative of a non-specialist reader, I
don't favor this choice. But it is the WG's decision to approve, not
mine.
> 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.
Thanks.
> 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.
Also:
> [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.
Given that, as you say, G.709 doesn't explain the design choice, "just
referring to G.709" doesn't explain the design choice either. My
*point* was that the reader is left wondering why the choice was made.
Now, as you say "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.", and that is quite reasonable. One could
dispute whether it is the best choice, but it states the design criteria
that favor such a choice. (And particularly for the software-oriented
reader, it reminds the reader that optical networking has to cope with
practical hardware limitations.) And given that that reasoning is
unlikely to be a trade secret, I favor adding it in the appropriate
place.
> [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.
I see that you have added the final sentence to this paragraph in the
-14 version:
* ODU: Optical Data Unit. An ODU has the frame structure and
overhead, as defined in Figure 12-1 of [ITU-T_G709_2020]. ODUs
can be formed in two ways: a) by encapsulating a single non-OTN
client (such as SONET/SDH, Ethernet) b) multiplexing lower-rate
ODUs. In general, the ODU layer represents the path layer in OTN
networks. The only exception is the ODUCn signal (defined below)
which is defined to be a section layer signal. In the
classification based on bitrates of the ODU signals, ODUs are of
two types: Fixed rate, and flexible rate. Flexible rate ODU(s),
called "ODUFlex" have a rate that is 239/238 times the bit rate of
the client signal it encapsulates.
I was thinking of a change more like the one marked below, which IMHO is
shorter and more directly attached to the definition of ODUflex. I
suppose then you would remove the final sentence of the definition of
ODU.
* 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 ***(viz. 239/238)*** of the bitrate of the client signal it
encapsulates. ITU-T defines specific ODUflex containers that are
required to transport specific clients such as 50GE, 200GE, 400GE,
etc.
My apologies for misquoting the ratio as 239/237 in my review. I'm not
sure where I got that number from.
Dale
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
