Create minute-2024-01-30.md

minutes/minute-2024-01-30.md

@@ -0,0 +1,180 @@
+# YANG model for Optical Impairment aware Topology week (January 30th,2024)
+
+
+****Attendees****
+- [x] Dieter Beller
+- [] Aihua Guo
+- [x] Esther Lerouzic 
+- [x] Julien Meuric
+- [x] Italo Busi
+- [x] Gert Grammel --> partially 
+- [] Gabriele Galimberti 
+- [x] Yuji Tochio
+- [x] Enrico Griseri --> partially
+- [x] Sergio Belotti
+- [x] Roberto Manzotti
+- [] Daniel King
+- [] Victor Lopez
+- [] Haomian Zheng
+- [] Igor Bryskin
+- [] Dirk Schroetter
+- [] Brent Foster
+- [] Jiang Sun (CMCC)
+- [] Jan Kundrat
+- [] Eliana Vercelli
+- [] Jonathan Sadler
+- [] Reza Rokui 
+
+## 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.
+
+#### #130 "Documenting mandatory profile for OI applications"
+
+**AP: Esther** will provide a description of the various attributes that even if optional in the model, are needed for OI application. 
+These attributes will be described in specifc context.
+
+Let's try to have this list in a couple of weeks from now.
+
+**CLOSED**
+There is a first draft proposal from Esther
+see issue #130 https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/130 
+
+Please review and comment.
+
+### Review APs (action point) RFC9093-bis
+
+#### 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
+
+**PR#160 merged to the master branch**
+
+### Closed Issues RFC9093-bis 
+
+**PR#82 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/82 merged to the master branch**
+
+
+### 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
+
+The YANG update related to this issue have been inserted in the PR#160
+
+The issue is still open since a textual update is also needed.
+This is the text agreed to be inserted in the new version of I-D:
+
+> In order to support the modelling of multi bandwidth (parallel)
+> and multi stage (cascaded) amplifier like in picture xx, 
+> the OMS-element that describe an optical amplifier contains an unordered 
+> list of amplifier-element. The position of the elements is based 
+> on the following two attributes:
+> - the lower-frequecy and upper-frequecy attribute identiting the
+> set of amplifier-element that support a specific spectrum bandwidth
+> - the stage-order attribute allowing to define for each spectrum bandwidth
+> the cascade order of amplifier-element.
+> 
+> adding ascii picture related to MultiStageAmplifierExample.pptx 
+in the github https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/files/13860899/MultiStageAmplifierExample-sb.pptx
+> 
+> “The detailed representation of the amplifier stages is not always mandatory, 
+abstraction is allowed as long as the optical impairments of the multi-stage amplifier are properly modelled.
+> For example, the detailed representation of the cascade order details can be required in the case the OMS-Element has both the function
+of Amplifier and DGE (see section 2.5).”
+
+
+#### #145 "Update Security Considerations"
+
+About security is still open the discussion about the rw vs. ro data nodes.
+To summarize the issue , in the text proposed for security it is stated that the data nodes in the YANG module are not writable , are readable only.
+Gert observed that a couple of data nodes "protection-type" and "inter-layer-sequance-number" are rw. 
+Gert suggested we should consider our OI topology model as "information-source-entry" in RFC8795 representing readable topology information
+while RFC8795 is also able to modify data nodes adding links/nodes , obtaining a combination of the real topology and what if something is added
+in the model. 
+As stated in the previous meeting we have kept some data nodes as rw for consistency with RFC8795.
+The topology models have been defined as rw to support other UCs 
+where the topology information can be written by the client applications and we have defined the LTP protection-type as rw to be consistent
+with the link-protection-type attribute defined in RFC8795 that we are using to report OMS protection configuration
+Both Esther and Italo commented that there are use cases that could justify to have e.g. protection-type rw.
+If it is possible to modify protection-type for OMS protection it should also be possible to modify protection-type
+for OTSi protection using the augmented data node in our OI topology model. This would be a use case justifying the possibility 
+to use writable data nodes also in our topology model, independently of RFC8795.
+
+### Discussion
+
+We discussed the last update of the YANG model with the two PR being merged.
+Sergio mentioned the new PR#89 of RFC9093-bis.
+One of the issue addressed in this PR was issue #85 https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/issues/85
+to change line-coding-bitrate within the grouping common-transceiver-configured-param into config true. 
+This request is coming form wdm-tunnle discussion where it was stated the need to have the possibility to configure line-coding-bitrate.
+This is not possible into Optical Impairment model where the leaf is defined as read-only.
+
+Linked to this issue it has been discussed a comment sent by Esther related to this issue.
+The comment is at https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/issues/85#issuecomment-1916605877.
+
+Esther said that she would like to use OI model not only as read-only model representing data extracted from the field but also using the model
+to feed a tool that could be a path computation , a validation tool.
+In this case the topology data can be not only "extracted" data but also synthetic data that means data simulated for a what-if scenario
+(e.g. I can add a link in the topology or change the bandwidth in a link).
+The request would be to have a single model (RW model) that can be utilized in different use cases, both as e.g. exctraced data but also
+as input for some tools.
+
+For the moment the decision from the group was to stay with the present read-only model, the changing from read-only to read-write is a BC change
+so that it can be made with a OI model-bis. 
+It was also agree anyway to add a text in the introduction of the OI draft, explaining that the model is a read-only model ,
+but nothing preclude in the future to change data model into RW to address other use cases in addition of exctracting data from the network
+to give a controller OI topology information for path computation.
+
+We stated also to discuss of new issue raised by Esther , issue#164. 
+In particular Esther pointed out the need to make the OI model less verbose in case of big network. 
+Next week we will go through more in details on this topic. 
+
+### Post Meeting notes:
+
+As a post-meeting note, Italo made some considerations about BC considerations in the hypothesisto move from RO to RW some data nodes.. 
+
+This is the text in RFC7950:
+
+   o  A node that represented state data may be changed to represent
+      configuration, provided it is not manadatory (Section 3).
+
+Another subtle topic is related with the keys for the lists. Having a key for RO lists is not required but having a key for RW lists
+is mandatory and adding a key to an existing list does not look like a BC change according to RFC7950