Change:
2.3.3. <del> The definition of the MC is currently being moved from ITU-T Recommendation G.872 G.872 to the new draft Recommendation G.807 (still work in progress) [G.807].  Section 3.2.2 defines the term MC and section 7.1.2 provides a more detailed description with some examples.  The definition of the MC is very generic (see ITU-T draft Recommendation G.807, Figure 7-1).  In the YANG model below, the MC is used with the following semantics: </del> <ins> G.807 defines a "media channel" as "A media association that represents both the topology (i.e., the path through the media) and the resource (i.e., frequency slot or effective frequency slot) that it occupies."  In this document, the term "channel" is occasionally used to indicate the resource of an MC (i.e., frequency slot or effective frequency slot), without representing topology. </ins> The MC is an end-to-end topological network construct and can be considered as an "optical pipe" with a well-defined frequency slot

Discussion:
draft-ietf-ccamp-optical-impairment-topology-URL for IETF 113 submission --> draft-ietf-ccamp-optical-impairment-topology-yang-URL Related to pull request . Addressing and resolving several open issues.
+1 the TE-node doesn’t include BA/PA, a physical node however could.
In TIP, carrier use cases exist for copropagating Raman. It has been verified that gnpy can model those by indicating the direction (see snippet below). So the provisional limit to consider only counterpropagating raman in can be lifted. example: "ramanpumps": [ { "power": 224.403e-3, "frequency": 205e12, "propagationdirection": "coprop" }, { "power": 231.135e-3, "frequency": 201e12, "propagation_direction": "coprop" }
There is agreement to introduce also co-propagating option. The model as it is can support the feature using type-variety. Only one point has to be verified: if in the case of co-propagation we can report the gain. he pump power is in the type-variety. The text in the draft has to updated without the limitation of counter-propagating.
During the meeting on February 15th , we agree to add two attributes pump-power and frequency. Also direction has to be added in alignment with the GNPy . Need to clearly say in the text that these attributes are needed for RAMN only.
Meeting 02/15/22: The agreement was to add "pump-power", "frequency" and "direction" attributes as described in Gert's comment URL Meeting 02/22/22: Esther sent a proposed description of attributes to TIP experts for revision .
From Esther: Compared to GNPy data model, the pumps are listed in an ‘amplifier element’, not in a fiber. I have assumed that a given amplifier element can not hold the two co and contra propagation roles.

Final result: “Raman-direction”: "counter-propagating" "Raman-pumps": [ { "power": 224.403e-3, "frequency": 205e12, }, { "power": 231.135e-3, "frequency": 201e12, } ] Descriptions: Raman-pumps container: list of pumps for the Raman amplifier Power: Total pump power in W considering a depolarized pump at frequency “frequency” Frequency: Pump central frequency in THz Raman-direction: direction of injection of the pump in the OMS. Contra-propagating means that optical pumps are injected in opposite direction to the optical signal that is amplified (backward pump). Co-propagating means that the optical pumps are injected in the same direction to the optical signal that is amplified (forward pump). enumerate type “co-propagating” or “contra-propagating” This porposal has been sent also to TIP experts for comments .
ITU-T G.872 (12/2019) The draft text needs to be aligned with the latest revisions of the referenced ITU-T Recommendations G.807 and G.872.
I have a mixed feeling about this ... On one side, I can understand that using the terms OTS/OMS MCG would align the terminology used in the draft with the ITU-T G.807 terminology On the other side, the OTS/OMS MCG from a topological perspective are modelled as links (at least the OMS MCG) so I am not sure whether the term MCG to represent a link would cause some confusion
Here is the text update I prepared with the objective to align with ITU-T G.807 and describe how the new terms map to the IETF TE-topology terminology: OMS Media Channel Group According to [G.807] and [G.872], an OMS Media Channel Group (MCG) represents a topological construct between two WDM-TE-nodes. In TE- topolgy terms, an OMS MCG corresponds to a WDM TE-link interconnecting two WDM-TE-nodes.

Specifically, it originates at the ROADM in the source WDM-TE-node and terminates at the ROADM in the destination ROADM including the Booster Amplifier (BA) and the Pre- Amplifier in the WDM-TE-nodes as well as In-Line Amplifiers (ILAs). OTS Media Channel Group represents a link: (i) between a WDM-TE-node's BA and the adjacent ILA, (ii) between a pair of ILAs, (iii) between an ILA and the adjacent WDM-TE-node's PA. An OMS MCG can be decomposed into a sequence of OTS MCGs of type (i), (ii), and (iii) as listed above. An OMS MCG (TE-link) provides the optical impairment data for its elements defined in the layer-0 topology YANG model and can be retrieved by a network controller. For the sake of optical impairment modeling, an OMS MCG can also be decomposed into a sequence of elements such as BA, fiber section, ILA, concentrated loss, and PA. An OMS MCG is terminated on both ends by a link termination point (LTP) as defined in [RFC8345]. Links in optical transport networks are typically bidirectional but have to be modeled as a pair of two unidirectional links following the [RFC8345] modeling approach. Unlike TE-links, which are unidirectional, the LTPs on either end of the TE-link pair forming the bidirectional link, are bidirectional as described in [I-D.ietf-teas-te-topo-and-tunnel-modeling] and the pair of unidirectional links are connected to the same bidirectional LTP on either end of the link pair.
few nits: The OMS-MCG starts from the ROADM element in the WDM-TE-node, but the description of OTS-MCG doesn't cover the link between ROADM element and Booster/PA. To cover this, a case iv should be added. (see G.807 Fig 11-1) last paragraph: [RFC8345] does not specifically define LTPs. It defines Termination Points (TPs) in a generic manner.

So "LTP" would better be replaced by "TP"
NAME NAME : thanks Gert to pointed out, we need to substitute RFC8345 with RFC8795, since LTP it is a a te-topology defined entity.
Fixed by PR
Elements as they are defined may be enough to handle Raman amplification, but I would like to have the feedback from the group about the possible missing attributes or change to the model. For example, it is not said in the model if the loss of the fiber should be its loss with or without Raman gain if any.
As per action point, here is a proposal for the text: "Hybrid backward Raman + EDFA amplification can be modelled for example by using an amplifier element in front of the EDFA amplifier element to represent the amplifier pump place and the resulting gain. In this case tilt target is not mandatory" (Ithink that nominal power should not be mandatory either, this is not something configurable) "In case of Raman amplification on a fiber section, the total-loss of the corresponding fiber element should contain only the fiber loss and not the resulting loss including Raman gain".
Here is a revised text proposal for section "2.4. Amplifiers": some editorial as well as format changes have been made to the a new paragraph on Raman amplifiers has been added (paragraph at the bottom below) addressing the modeling approach for Raman amplifiers the remaining text in this section is unchanged
Thanks, that's clear for me ! shall we also amend the model and put nominal-power as optional ?
NAME : sorry ,which nominal-power are you referring to?
I was refering to nominal-carrier-power and nominal-power-spectral-density, but I just realized that they are already optional !
I would propose some text update to the last part of Dieter's text proposal: The remaining text proposal from Dieter is fine for me
NAME
I like NAME proposal including NAME amendments: however I'm wondering if it's worth mentioning the amplifier element shall model Ramam gain tilt and bandwidth as well. something like an amplifier element at the pump location which reports all the optical properties (gain, tilt, etc) of the Raman amplification.

NAME NAME NAME What about: "an amplifier element whose location (provided by both the position in the OMS-link list of elements and geolocation) reports the pump place and whose parameters reports all the optical properties (gain, tilt, etc) of the Raman amplification.
I’m OK with the text with only one comment: there are co-propagating and counter-propagating raman pumps, do We want to limit the solution to counter-propagating pumps ?
Here the text we agree during the December 14th meeting: Amplifiers Optical amplifiers are used in WDM networks for amplifying the optical signal in the optical domain without any optical to electrical and electrical to optical conversion. There are three main optical amplifier technologies: o Erbium Doped Fiber Amplifiers (EDFAs) o Raman Amplifiers o Semiconductor Optical Amplifiers (SOAs) In today's WDM networks EDFAs and Raman amplifiers are widely used. Raman amplifiers have become attractive due to their large spectral gain bandwidth, which can be quite flat, with similar or even lower noise figures compared to EDFAs. On the other hand, Raman amplifiers consume more power and are usually more expensive than EDFAs. Raman amplifiers are distributed amplifiers where an optical pump signal is injected in opposite direction to the optical signal that is amplified (backward pump). Due to the distributed nature of the Raman amplifier it is difficult to clearly separate the amplifier from the fiber span into which the pump signal is injected. From a topology modeling perspective, the Raman amplifier is modeled as two OMS link elements: a passive fiber element whose loss accounts only the fiber loss and not the resulting loss including Raman gain an amplifier element whose location (provided by both the position in the OMS-link list of elements and geolocation) reports the pump place and whose parameters reports all the optical properties (gain, tilt, etc) of the Raman amplification
During December 14th meeting it was decided that is acceptable, for the moment, to limit the solution to counter-propagating pumps only. An explicit sentence regarding this point will be added , together with the text suggested by Dieter.

Updated section 2.4 text addressing the previous comment, text proposal from Dec 14, 2021, slightly modified - pure editorial changes only - see numbered list items at the bottom: Amplifiers Optical amplifiers are used in WDM networks for amplifying the optical signal in the optical domain without any optical to electrical and electrical to optical conversion. There are three main optical amplifier technologies: o Erbium Doped Fiber Amplifiers (EDFAs) o Raman Amplifiers o Semiconductor Optical Amplifiers (SOAs) In today's WDM networks EDFAs and Raman amplifiers are widely used. Raman amplifiers have become attractive due to their large spectral gain bandwidth, which can be quite flat, with similar or even lower noise figures compared to EDFAs. On the other hand, Raman amplifiers consume more power and are usually more expensive than EDFAs. Raman amplifiers are distributed amplifiers where an optical pump signal is injected in opposite direction to the optical signal that is amplified (backward pump). Injecting the pump signal in the same directions as the optical signal that is amplified (forward pump) is currently not considered. Due to the distributed nature of the Raman amplifier it is difficult to clearly separate the amplifier from the fiber span into which the pump signal is injected. From a topology modeling perspective, the Raman amplifier is modeled as two OMS line elements: a passive fiber element accounting for the fiber loss only and not the resulting loss including the Raman gain an amplifier element providing all optical amplifier properties (gain, tilt, etc.). On the OMS-link, the amplifier element is placed where the pump is located and the geolocation information also indicates the location of the pump.
NAME I like the editorial modifications and new structure of the text, with the numbered list bullets at the bottom.
Thanks, Ok for me!
NAME The new formulation is fine for me (and it will address NAME comment too).
Fixed by PR
We would like to use the model to describe a topology where the ROADMs have one/multiple external shelves with OTs. For management reason we want to represent the external shelf as a te-node (in the ietf model), to represent all names and adresses (we do not want to represent the shelf+ROADM as a single abstract ROADM).

The links between the OTs hosted in this shelf can be described using te-link with optical impairment augmentation to describe possible loss or noise (the tooling provided by the model is enough to handle this case). However the external shelf does not contain any mux, so that the link between the remote transceiver and the ROADM is not an OMS. However all the impairments we have defined in our model have this 'OMS' attribute. This mismatch between the name of the attributes (containing OMS) and its usage for non OMS links might be confusing for implementers. We thus would like to say explicitely in the draft that the links between ROADMs and external shelves can also be described with our model. Currently, this sentence is in the draft: for example in the client device with a single channel link between the OT and the add/drop port of the ROADM requires further investigations and will be addressed in a future revision of this document.] Would it be possible instead to say: The impairments related to the link between remote optical transponders located in a different shelf from the ROADM itself, can also be modelled using the same optical impairments as those defined for a link between ROADMs (OMS).
in the scenario the external shelf can be considered as TE-node with termination capability only (not switching) the external shelf is under the control of the same controller as the ROADM
the external shelf is under the control of the same controller as the ROADM : the text is no more used . -AP: NAME to add specific issue to clarify how the link between external shelf and ROADM is discovered . No impact on this issue that we can consider as closed .
This is the "agreed" text , to be added in the draft in the next version upload (by IETF-113): "The impairments related to the link between remote optical transponders located in a different shelf from the ROADM itself, can also be modelled using the same optical impairments as those defined for a link between ROADMs (OMS).

In the scenario the external shelf can be considered as TE-node with termination capability only (not switching)"
Let me suggest a couple of tweaks: "The impairments related to the link between remote optical transponders, located in a different node from the ROADM itself, can also be modeled using the same optical impairments as those defined for a link between ROADMs (OMS). In this scenario, the transponder-carrying node can be considered as TE-node with termination capability only (i.e. no switching)."
NAME : Thanks Julien for the suggested modifications, why at this point do not use the terminology proposed in issue ? "The impairments related to the link between remote optical transponders, located in a different WDM-TE-node from the ROADM itself, can also be modeled using the same optical impairments as those defined for a link between ROADMs (OMS). In this scenario, the transponder-carrying node can be considered as WDM-TE-node with termination capability only (i.e. no switching)."
NAME If we agree on the terms in , I concur: we MUST use them here.
Fixed by PR