Create minutes-2022-03-08.md

minutes-2022-03-08.md

@@ -0,0 +1,109 @@
+# YANG model for Optical Impairment aware Topology weekly (March 08th,2022)
+
+
+****Attendees****
+- [x] Dieter Beller
+- [] Aihua Guo
+- [x] Esther Lerouzic
+- [x] Julien Meuric
+- [x] Italo Busi
+- [x] Gert Grammel
+- [] Gabriele Galimberti 
+- [x] Yuji Tochio
+- []Enrico Griseri
+- [] Sergio Belotti
+- [] Victor Lopez
+- [] Haomian Zheng
+- [x] Igor Bryskin
+- [] Brent Foster
+- [] Jiang Sun (CMCC)
+- []Jan Kundrat
+
+
+
+## Discussion
+
+
+### Review APs (action point) 
+
+#### AP OTSi global unique identification: Dieter to propose text
+##### status: ON GOING
+##### issue #88 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/88
+
+
+#### AP on discovery: AP @Italo  to add specific issue to clarify how the link between external shelf and ROADM is discovered
+##### status: ON GOING
+
+### issues on agenda
+
+
+#### issue#102 : copropagating raman
+https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/102
+
+The agreement was to add "pump-power", "frequency" and "direction" attributes as described in Gert's comment
+https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/102#issue-1126058417
+
+#### AP @Esther: to check with PoliTO at TIP-OOPT-PSE WG possible description of pump-power and frequency.
+##### status : done 
+
+We got positive answer and approval of our solution by PoliTO experts in TIP. 
+The proposed YANG proposal has been added in the YANG update of PR#104 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/pull/104
+
+The issue #102 has been closed with the update for IETF-113
+
+#### issue#24 : Model alignment with 400G-ZR
+https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/24
+
+* There was a common agreement that the model is already suitable for any pluggable , no needs to have a specific model to cover 400G ZR+
+* ZR+ is specified in OpenROADM , and as such it can be managed as an “MSA” fora organizational mode, see section 2.5.2 
+that already mention for a as part of organizational mode case.
+* We need to be sure that this MSA organizational mode can be a superset of the list of explicit attributes.
+Need to be check the list of needed parameters for ZR+ (Gabriele)
+* There could be an OTN compatibility issue for ZR+ that has to be verified. This could be an issue in case of 3R. 
+Not only for ZR+ we could consider the opportunity to add an attribute to provide information regarding digital compatibility.
+
+In general:
+* The model with operational modes seems providing already way to manage compatibility issues
+* We should probably digging more in scenario with 3R, but also in this case seems that operational mode could be enough.
+* Client information are input of path computation, and are not part of the topology model. We can suppose that other model already provided this information.
+* In case of zr+ we can add sentence to specify to be careful about operational modes e.g. you could have zr+-ethernet and zr+-otn
+* The way happens ODUflex ODUCn mapping is an input to path computation. Maybe operational mode could be not sufficient. 
+AP @Italo to check with ITU guys.
+
+Gabriele was out of the meeting and we decided to wait for him to analyse more carefully his comment on
+https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/24#issuecomment-1054238457 before closing eventually the issue
+
+### issue on layer0-types-ext PR for IETF-113
+
+2 issues have been raised by Esther during the review of the YANG update done for IETF-113 PR#36 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/pull/36
+
+#### issue#38 Shouldn't penalty be a decimal value: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/38
+
+The decision was that the penalty should be decimal and we can add a new typedef e.g. decimal-in-db with 2 digits similar to power-in-db:
+typedef power-in-db {
+    type decimal-2-digits;
+    units dB;
+    description
+      "The power in dB.";
+}
+
+#### issue#39 Shouldn't max-diff-group-delay be a decimal value: https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/39
+
+The decision was that "picosecond" is a standard unit of measuring time and having integer is acceptable (uint32).
+
+### Esther's feedback from TIP-MUST
+
+About the amplifier model operators (not Orange) want to have a model able to have a more detailed description of amplifiers. 
+In IETF we have abstracted some details since the type and characteristic of any amplifiers are described with type-variety pointing to an external library.
+Instead operators want to have a choice on how to describe the amplifier.
+They want to get information from device instead to exploit from external library.
+Eshter observed that also n case of type-variety you could built automatically the library out of device, 
+in this case it would be more accurate than if the library would be obtained by external means.
+What operator saying is that they want a model that if vendors are providing more parameters they need a model permitting to manage directly
+all these parameters e.g. for gain we provide actual-gain , no 4 coefficient for polinomial computation.
+
+In conclusion, there is no a direct impact on our model but we need to monitor the situation and maybe in future to be open to change
+the model in line with what done for transponder with a "choice" among organizational, G.698.2 or explicit modes.
+
+
+## next meeting: March 15th 2022