Change:
Figure-1 shows the control plane architecture. <del> The models developed in this document is an abstracted YANG model that may be used in the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure-1.  It is not intended to support a detailed low-level DWDM interface model.  DWDM interface model is supported by the models presented in I-D.ietf-ccamp-dwdm-if- param-yang. </del> <ins> The topology model developed in this document is an abstracted topology YANG model that can be used at the interfaces between the MDSC and the Optical Domain Controller (aka MPI) and between the Optical Domain Controller and the Optical Device (aka SBI) in Figure- 1.  It is not intended to support a detailed low-level DWDM interface model.  DWDM interface model is supported by the models presented in I-D.ietf-ccamp-dwdm-if-param-yang. </ins> 2.2. <del> This section provides the description of the reference optical network architecture and its relevant components to support optical impairment-aware path computation. </del> <ins> This section provides the description of the optical transport network reference architecture and its relevant components to support optical impairment-aware path computation. </ins> Figure-2 shows the reference architecture. <del> BA (on the left side ROADM) is the ingress Amplifier and PA (on the right side ROADM is the egress amplifier for the OMS link shown in Figure-2. </del> <ins> BA (on the left side WDM-TE-node) is the engress Amplifier and PA (on the right side WDM-TE-node is the ingress amplifier for the OMS Media Channel Group (MCG) Figure-2. </ins> 2.3. <del> According to G.872, OMS Media Link represents a media link between two ROADMs.  Specifically, it originates at the ROADM's Filter in the source ROADM and terminates at the ROADM's Filter in the destination ROADM. OMS Media link can be decomposed in a sequence of OTS links type (i), (ii), and (iii) as discussed above.  OMS Media link would give an abstracted view of impairment data (e.g., power, OSNR, etc.) to the network controller. For the sake of optical impairment evaluation OMS Media link can be also decomposed in a sequence of elements such as BA, fiber section, ILA, concentrated loss and PA. An OMS Media link 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 </del> <ins> According to G.807 and G.872, an OTS Media Channel Group (MCG) represents a topological construct between two adjacent amplifiers, such as: According to G.807 and G.872, an OMS Media Channel Group (MCG) represents a topological construct between two WDM-TE-nodes. Specifically, it originates at the ROADM in the source WDM-TE-node and terminates at the ROADM in the destination WDM-TE-node including the Booster Amplifier (BA) and the Pre-Amplifier (PA) in the WDM-TE- nodes as well as the In-Line Amplifiers (ILAs) between the two WDM- TE-nodes. An OMS MCG can be decomposed into a sequence of OTS MCGs and amplifiers. An OMS MCG can be described as a sequence of elements such as BA, fiber section, ILA, PA, and concentrated loss wherever there is an insertion loss caused for example by a fiber connector. In TE-topology terms, the OMS MCG is modeled as a WDM TE-link interconnecting two WDM-TE-nodes.  A network controller can retrieve the optical impairment data for all the WDM TE-link elements defined in the layer-0 topology YANG model. The optical impairments related to the link between remote optical transponders, located in a different WDM-TE-node (an IP router with integrated optical transponders for example), can also be modeled as a WDM TE-link using the same optical impairments as those defined for a WDM TE-link between WDM-TE-nodes (OMS MCG).  In this scenario, the node containing the remote optical transponders can be considered as WDM-TE-node with termination capability only and no no switching capabilities. 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 </ins> 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. <del> [Editor's note: text below related to G.807 needs to be revised! G.807 is now in publication process.] </del> <ins> [Editor's note: text below related to G.807 needs to be revised based on the published G.807 revision!] </ins> 2.3.1.

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