Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
c19af09
commit 7d393c6
Showing
1 changed file
with
206 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,206 @@ | ||
| # YANG model for Optical Impairment aware Topology week (January 16th,2024) | ||
|
|
||
|
|
||
| ****Attendees**** | ||
| - [] Dieter Beller | ||
| - [x] Aihua Guo | ||
| - [x] Esther Lerouzic | ||
| - [x] Julien Meuric | ||
| - [x] Italo Busi | ||
| - [x] Gert Grammel | ||
| - [x] Gabriele Galimberti | ||
| - [x] Yuji Tochio | ||
| - [x] Enrico Griseri | ||
| - [x] Sergio Belotti | ||
| - [x] Roberto Manzotti | ||
| - [x] Daniel King | ||
| - [] Victor Lopez | ||
| - [] Haomian Zheng | ||
| - [] Igor Bryskin | ||
| - [] Dirk Schroetter | ||
| - [] Brent Foster | ||
| - [] Jiang Sun (CMCC) | ||
| - [] Jan Kundrat | ||
| - [] Eliana Vercelli | ||
| - [] Jonathan Sadler | ||
| - [x] 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. | ||
|
|
||
|
|
||
| ### 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 approved and ready to be merged pending merging of RFC9093-bis PR#82 | ||
|
|
||
| ### 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 | ||
|
|
||
|
|
||
|
|
||
| ### 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 | ||
|
|
||
|  | ||
|
|
||
| status: | ||
| * Roberto has proposed new text and YANG proposal ,see at | ||
| https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/153#issuecomment-1880596742 | ||
| * Italo to propose a more generic text for the last part | ||
| * multi-band amplification in parallel. | ||
| * 3 elements in sequence per band. | ||
|
|
||
| YANG update | ||
| * new attribute as stage-order to characerize the stage of amplifier-element in the sequence | ||
| * "is-dynamic-gain-equalyzer" as mandatory attribute | ||
| * replicate type-variety at amplifier-element but as optional attribute | ||
| * adding a choice to have mandatory attributes as (gain, in_voa, out_voa,...) | ||
| mutually exclusive, so that when the attribute is-dynamic-gain-equalizer is present, | ||
| none of the mandatory attributes are present. | ||
|
|
||
| -Name, type_variety, frequency-range, power-param, pdl, stage-order can be common to both DGE and AMP | ||
| -dynamic-gain-equalizer and media-channel-group only for DGE | ||
| -actual-gain, in-voa, out_voa, total-output-power, tilt-target, rama-direction, raman-pump only | ||
| for amplifier | ||
|
|
||
| Still to be clarified: | ||
| - is needed the container to group the mandatory attributes in case the elemen is not a DGE ? | ||
| - Why media-channel-group only for DGE? | ||
|
|
||
|
|
||
|
|
||
| #### #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 | ||
|
|
||
| #### RFC9093-bis PR#82 review of Esther's comment | ||
|
|
||
| **common-transceiver-configured-param** | ||
| suggest to change the description since some of the parameters inside the grouping are dependent | ||
| on the configured operational mode e.g. line-coding-bitrate | ||
|
|
||
| *old description* "The configured parameters of an optical transceiver, | ||
| which are independent from the configured operational mode" | ||
| *new description* "parameters which supplement the configured mode" | ||
|
|
||
| The operational mode or application code may define the constraints of how | ||
| these parameters can be set (e.g., min/max nominal central frequency or the list of allowed values | ||
| for the line coding bitrate). | ||
|
|
||
| The constraints defined by the operational mode or application code sometimes may be strict and allow | ||
| a single value to be configured (e.g., some application codes support only one line coding bitrate): | ||
| in this case, the configuration of the attribute is optional | ||
| and the only value allowed by the operational mode or application code | ||
| can be applied as default by the system. | ||
|
|
||
| Could be usefull to add an example showing how this grouping suplement the operational/application mode | ||
| configured e.g. in the case of tunable (multi bitrate) or fix transponder (single bitrate). | ||
|
|
||
| **WDM Label and Label Range and frequency slot definition** | ||
|
|
||
| esther's comment https://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis/pull/82#discussion_r1440308861 | ||
|
|
||
| A*P @italo @sergio* : Need to add a sentence to underline that while following the ITU-T G694.1 | ||
| flexible.grid definition , NCFG and SWG are fixed to 6.25GHz and 12.5GHz respectively, | ||
| the model does not preclude using finer vendor-specific granularity of NCFG and SWG (e.g., 3.125 GHz) | ||
|
|
||
| #### Optical Impairment DGE guideline | ||
|
|
||
| **AP @Italo** to propose some text to generalize the text below:CLOSED | ||
|
|
||
| "The detailed rapresentation of the amplifier stage is not mandatory in general, | ||
| but in the case the OMS-Elemtn has both the funtion of Amplifier and DGE (refer | ||
| section 2.5) the implementation MUST provide the cascade order details of | ||
| amplifier element in order to allow a proper modelling of the impairment" | ||
|
|
||
| *New text*: | ||
| "The detailed rapresentation 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)." | ||
|
|
||
| **The text from Italo was agreed**. | ||
|
|
||
| Since the presence in the text of the word "mandatory" , that is a BCP14 keyword, | ||
| that word should be capitalized. | ||
| For this reason the proper standard reference has to be added to use the capitalize character. | ||
|
|
||
| It was agreed: | ||
| -to use a new container to group the mandatory attributes in case the element is not a DGE | ||
| as proposed by Italo | ||
|
|
||
| -Why media-channel-group only for DGE? Because DGE is used per channel and that would imply | ||
| media-channel-group while amplifier is using all the spectrum wihtout separating channels, | ||
| media-channel-group will be in the DGE part. | ||
|
|
||
| No other issues to be discussed regarding DGE. |