Create minute-2023-12-12.md

minutes/minute-2023-12-12.md

@@ -0,0 +1,159 @@
+# YANG model for Optical Impairment aware Topology week (December 12th,2023)
+
+
+****Attendees****
+- [] Dieter Beller
+- [x] Aihua Guo
+- [x] Esther Lerouzic  (partially)
+- [x] Julien Meuric
+- [x] Italo Busi
+- [x] Gert Grammel
+- [x] Gabriele Galimberti 
+- [x] Yuji Tochio
+- [x] Enrico Griseri
+- [x] Sergio Belotti
+- [] Victor Lopez
+- [] Haomian Zheng
+- [] Igor Bryskin
+- [] Dirk Schroetter
+- [] Brent Foster
+- [] Jiang Sun (CMCC)
+- [] Jan Kundrat
+- [] Eliana Vercelli
+- [] Jonathan Sadler
+- [x]Roberto Manzotti
+- [x]Daniel King 
+
+## Admin
+
+### Review APs (action point) Optical Impairment Topology YANG model
+
+####issue #124 "*Remove key from media channel list*"
+related to flexi-n value there is agreement to go ahead to delete the key statements from the media-channel-group/media-channel lists, making the flexi-n attribute optional.
+A possible issue without key is to have more elements with the same flexi-n and we cannot have 2 media-channel with the same flexi-n.
+
+**AP: Italo/Aihua** to have a look to possible YANG statement (e.g.unique statement) to overcome the issue
+
+Need to make some json examples and make the validation with yanglint.
+You cannot have two media channel in the same media channel group with the same flexi-n. See figure 5 in section 2.3.4
+
+       +--ro media-channel-groups!
+       |  +--ro media-channel-group* [i]
+       |     +--ro i                 int16
+       |     +--ro media-channels* []
+       |        +--ro flexi-n?          l0-types:flexi-n
+       |        +--ro flexi-m?          l0-types:flexi-m
+
+Need to check if "unique" statement is still valid when flexi-n is not present.
+Esther: flexi-n if it exists must be unique in the media-channel-group upper level list.
+
+
+### Review APs (action point) RFC9093-bis
+
+#### Issue #10 "Need for frequency and power range attributes also with Standard Mode"
+
+it seems that G.698.2 does not mandate transceivers to be tunable nor to support tunability for the whole frequency range between the minimum and maximum frequency.
+Then *it could be useful to add also to the standard mode the attributes used to report the frequency and power ranges supported by a given transceiver for a 
+given application code*
+
+**AP: @Italo @Sergio: to check off-line with Q6 experts if our understanding is correct**
+**CLOSED** : see comment https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/issues/10#issuecomment-1840881681 in the issue#10 
+Update to the model has been already settled in the PR#82 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/82
+
+#### Issue #21 "Review otu-type identities"  
+https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/issues/21
+
+**AP: @Aihua: to verify with Haomian if these otu identities are needed and where they are defined (some, but not all, are defined in G.Sup43)**
+
+### Closed Issues Optical Impairment Topology
+
+Closed issues from last IETF117 has been reported in the presentation during IETF118 
+
+issue #134 "Try to shorten the names of attributes"
+issue #155 "Absolute path in grouping power-param", 
+issue #158 "delta-power contains a ratio in dB. one may call it gain, however gain is only positive, where delta_p could be negative. so the type should be changed",
+issue #159 "remove from the model grouping sliceable-transponder-attributes"
+
+There is a proposal to solve these issue in PR#160 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/pull/160
+
+### Closed Issues RFC9093-bis 
+
+see new PR#82 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/82
+
+see the description of YANG updates at https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/82#issue-1992861226
+
+-added "ratio-in-db and ratio-in-db-or-null" related to issue#158 in Optical Impairment 
+-renamed decimal-16-digits and decimal-16-digits-or-null as power-spectral-density and power-spectral-density-or-null
+
+
+### Next calls
+
+
+### Optical Impairment Topology YANG model
+
+#### #153  "Adding guideline for DGE representation"  
+https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/153
+
+![](https://)![](https://s3.hedgedoc.org/demo/uploads/95d5cf7d-91a7-4fe7-bb7a-989dc398f102.png)
+
+
+
+#### #145 "Update Security Considerations"
+
+Sergio uploaded to github a first draft for security section.
+
+#### #130 "Documenting mandatory profile for OI applications"
+
+JSON file uploaded as comment to github will be put together with the other json-examples in githug not in the draft appendix since too long.
+
+Esther will provide a description of the various attributes that even if optional in the model, are needed for OI application. 
+This attributes will be described in specifc context.
+
+
+
+### Discussion
+
+#### DGE guideline issue#153- Optical Impairment 
+
+Roberto made some internal check : the equipment in discussion is a two stage in-line amplifier + equalizer with not too much dynamic (max 6db). 
+In this common scenario it is expected that the OSNR should have negligible variation across the spectrum and should not trigger accuracy issue in the optical simulation. In any case the intent is to prepare some examples OSNR calculation to confirm the above assomption. 
+
+Roberto and Enrico simulated a possible scenario for a dual stage amplifier and the DGE component in the middle to verify the impact of the 
+equalization on the OSNR of different channels.
+The simulation is contained in an uploaded file (https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/13549354/DGE.OSNR_short.pdf)
+
+@EstherLerouzic please review the attached slides prepared by @egriseri
+
+Esther said she have been looking at the slides but she asked for a conclusion coming from this analysis: do we need to think about the introduction of some new parameters
+to report the range of accurancy ?
+It was decided to move the discussion to a specific call on the subject,
+possible date Monday , December 18th , 2pm CET.
+If further analysis would be needed we will dedicate time also in the next weekly call on Dec 19th.
+
+#### Update security Consideration issue#145- Optical Impairment
+
+Daniel King provided an update of the text proposal uploaded by Sergio.
+Here the link of the updated text https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/13640706/security-OI-Topology.v1.docx
+
+We reviewed the updated text from Daniel, 
+2 points:
+-to add referecne aslo to RFC 8795 security consideration 
+-Gert observed that there are some data nodes , inparticular for protection that can be also configured and so the text should be slightly adapted.
+
+Daniel will take the action to update the text.
+
+
+#### Boundary between Layer 0 and Layer 1 issue#81- RFC9093-bis
+
+see Gert's comment at https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/issues/81#issuecomment-1850538532
+
+Gert made a cross reference between a set of slides that basically putting L0 boundary at OTSi termination, a liaison clarifying the meaning of the OTSi, 
+defined in ITU-T G.959.1, and RFC1208 that practically associating Layer-1 to a bit-stream, 
+which is the input of a modulator and the output of a de-modulator, while OTSi is the signal between the modulator and demodulator.
+
+Italo observed that the work to be done to verify that the model would be aligned with this boundary, is to verify that all the functions needed for L0 would 
+be already described in the model.
+3R for example is a L1 functionality at ODU level but we modeled that in L0, with the justification that 3R can be needed as output of L0 path computation,
+so we need to have that in L0 model.
+
+We think that the issue is not a blocking point for the model in the LC preparation and that the work on that can be done in parallel to the remaining blocking issues.