diff --git a/minutes/minute-2024-01-30.md b/minutes/minute-2024-01-30.md new file mode 100644 index 0000000..c72ae7f --- /dev/null +++ b/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