Attendees
- Dieter Beller
- Aihua Guo
- Esther Lerouzic
- Julien Meuric
- Italo Busi
- Gert Grammel
- Gabriele Galimberti
- [] Yuji Tochio
- Enrico Griseri
- Sergio Belotti
- 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
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.
ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#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: Agreed to define identities only for the standard OTU types defined in G.709
PR#89 ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#89 merged to the master branch
February 20th, 2pm CET
YANG update has been already addressed in the context of PR#160
On the base text proposed by Roberto and Italo, an editorial refined version
has been proposed by Dieter for agreement
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.
We started discussing a suggestion from Esther to modify the leafrefs added to the *container compatible-modes *when transceiver-mode grouping is used in transceiver-capabilities grouping.
uses transceiver-mode {
augment "mode/explicit-mode/explicit-mode/"
+ "compatible-modes" {
description
"Augments the compatible modes with the proper
leafrefs.";
leaf-list supported-application-codes {
type leafref {
path "../../../../supported-mode/mode-id";
}
must "../../../../"
+ "supported-mode[mode-id=current()]/"
+ "standard-mode" {
description
"The pointer is only for application codes
supported by transceiver.";
}
description
"List of pointers to the application codes
supported by the transceiver's explicit mode.";
}
leaf-list supported-organizational-modes {
type leafref {
path "../../../../supported-mode/mode-id";
}
must "../../../../"
+ "supported-mode[mode-id=current()]/"
+ "organizational-mode" {
description
"The pointer is only for organizational modes
supported by transceiver.";
}
description
"List of pointers to the organizational modes
supported by the transceiver's explicit mode.";
}
}
}
Agenda for today :
RFC9093-bis
- ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#88 Update wavelength assignment definitions
- ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#92 Adopting new identities for wavelength assignment mechanism
The two issues above are related to the same context, so we have closed issue#88 . No concern to move the two identities defined wavelength assignmen from WDM tunnel to RFC9093-bis
- ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#91 Check yanglint compilation errors
The issue is related to errors reported on the datatracker. Need to be studied the reason of these errors. On going.
- ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#21 Review otu-type identities We need to verify if needed or not in other models. We can use the same sentence present in L1 types about the reference. Remove the not-standard OTU types and add a sentence like L1 types about not standard reference. We keep otu-type identity as base identity and remove only the proprietary types.
ietf-ccamp-wg/ietf-ccamp-layer0-types-ext-RFC9093-bis#90 Authors on the front page
Need to check with Haomian and Dan if they are fine to be moved as contributors due to limit number of front page authors.
Optical Impairment draft
- #164 Found some inconsistency while profiling
• amplifiers: o out-voa and in-voa should be optional o type variety should be present and optional at amplifier-element level DONE
• fibers: o total-loss should be used to report computed loss based on measurement. So that inconsistency between computed loss based on loss_coef and length + connector loss means:
"Total loss is used to report loss measured with ingress and egress amplifier power measurement facility (power measured at ingress amplifier output to the fiber span - power measured at egress amplifier input from the fiber span in dB). This measurement may deviate from the computed loss based on length and loss-coef as it includes all loss contributions including possible lumped loss due to imperfect fiber splices, and connector losses. In case total-loss cannot be measured (no power measurement in place), it should not be reported."
This text need to be added to I-D text only (not need in YANG) DONE
• delta-power should be a ratio in db (I have open a specific issue for this one as it can be easily corrected) DONE
• extensive ROADM or Transceiver impairment for each ROADM or Transceiver explicit parameters instance in the network might become too verbose on large networks. If the same values are shared among same type of devices (par part-number or even per group of part-numbers), my preference would be to create a catalog at network level and refer to it in the roadm or transceiver instance.
DONE with PR#165 #165
- #153 Adding guideline for DGE representation
There is the last update from Dieter addressing Gert’s comment #153 (comment)
During the meeting the text was slightly modified for Gert's suggestion.
This is the new text:
"Multi-band amplifiers like the dual-band amplifier depicted in Figure 6 have a band-separating filter at the input and a band-combining multiplexer combining all the bands at the output. This filter and multiplexer functions are not modeled explicitly and their optical impairments are subsumed in the optical impairments of the amplifier components."
#145 Update Security Considerations
The proposed text by Dan/Sergio has been incorporated by Dieter in the draft . -the model is read-only -we need to add a sentence at the beginning of I-D, a text explaining that the network instance of OI in this version is containing only RO data nodes -need to analyze the model where we need update list with proper key to permit to move data node form RO to RW in the future.