Change:
I-D changes: Minor editorial updates Updated IANA considerations: YANG changes: Added 400G attributes: Changed frequency fraction digits: - Added units for max-diff-group-delay: Change the authors of the I-D and YANG model: Co-Authored-By: sergio belotti
The below definitions should be changed as the accuracy (fraction digit) can match only to 3.125 granularity. Should the granularity be finer the fraction digit needs to be extended (e.g. to 9 and 6 for THz and GHz). typedef frequency-thz { type decimal64 { fraction-digits 6; } units THz; description "The DWDM frequency in THz, e.g., 193.112500"; } typedef frequency-ghz { type decimal64 { fraction-digits 3; } units GHz; description "The DWDM frequency in GHz, e.g., 193112.500"; }
Dear Authors, Before the IETF meeting, we check documents listed on working group agendas for IANA-related issues. We have a couple of notes about this document: URL If this bis document had a longer set of IANA Considerations, we might have different advice, but in this case, we would recommend updating the section to read as follows: For the following URI in the "IETF XML Registry" [RFC3688], IANA has updated the reference field to refer to this document: URI: urn:ietf:params:xml:ns:yang:ietf-layer0-types Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace. This document also adds an updated YANG module to the "YANG Module Names" registry [RFC7950]: Name: ietf-layer0-types Namespace: urn:ietf:params:xml:ns:yang:ietf-layer0-types Prefix: l0-types Reference: this document When a document is obsoleted, the action for us is usually to update the original registration's reference field (unless the registration is being deprecated/obsoleted). The YANG Module Names registry is unusual in that we'll actually leave the current registration alone and instead make a second registration that links to the new version of the module and has the new document as its reference. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. If at any time you'd like an early review for any document, just send us a message at . Best regards, Amanda Baber IANA Operations Manager
I think Amanda is right and we should update the IANA sections as she suggests
The original authors of layer0-types have been completed deleted and disappeared from the draft. We need to add again the 4 original authors of layer0-types-ext . Maybe as co-authors at the bottom of the document. Alternative is to report all the authors in the front page and in a second time to make a choice for the from page and bottom of the draft. Originally posted by NAME in URL
We need to add authors present in the front page also in the YANG module.
400G-ZR is a non-OTN interface. Need to check if the current terminology used covers such interfaces too.
URL This was finally published yesterday.
Thanks a lot Sergio ! Best Regards, Gabriele [URL] Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy URL EMAIL Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049
Thanks Sergio Looking at section 7 (Use Cases), it seems that there are no OADMs between 400G-ZR transmitters and receivers I am wondering whether 400G-ZR use cases are relevant for the optical impairments topology since there are no OADMs and therefore there is no need for any path computation It looks like relevant only for the DWDM interface model
400G-ZR is relevant to the interface model 400G-ZR+ is relevant to the interface and DWDM model 400G with OFEC is relevant to the interface and DWDM Model (also 100G, 200G, 300G FlexO with OFEC)
Feedback from a meeting held on Thursday late afternoon: attendees : G.Galimberti, Esther Le Rouzic, D. Beller, I. Busi, S. Belotti There is a common agreement that the model is already suitable for any pluggable , no needs to have a specific model to cover 400G ZR+ZR+ is specified in OpenROADM , and as such it can be managed as an “MSA” fora organizational mode, see section 2.5.2 that already mention for a as part of organizational mode case.We need to be sure that this MSA organizational mode can be a superset of the list of explicit attributes. Need to be check the list of needed parameters for ZR+ (Gabriele)There could be an OTN compatibility issue for ZR+ that has to be verified. This could be an issue in case of 3R. Not only for ZR+ we could consider the opportunity to add an attribute to provide information regarding digital compatibility.
I did some check on the OpenZR+ and ZR specs on the optical parameters and payload. Either OpenZR+ and ZR do NOT support OTN. OpenZR+ The following (additional) parameters are included in the OpenZRP specs. No Application Codes are defined. Black-Link Polarization rotation speed Transmitter Opt. specs Tx output power with transmit disabled ? Inband (IB) OSNR ? Out-of-band (OOB) OSNR ? Transmitter polarization dependent power difference ? X-Y skew ? Receiver Opt. specs. PMD (avg) tolerance Peak PDL tolerance OIF – ZR 3 different Application Codes: 0x01 – 400ZR,100 GHz DWDM amplified 0x02 – 400ZR, Single wavelength, Unamplified 0x03 – 400ZR, 75 GHz DWDM amplified ZR has the same additional parameters of OpenZR+ OpenROADM specs support OTN but in a different form factor: CFP-2 DCO or other.
AP NAME NAME : to check internally with optical expert the real impact for topology model
We could add the parameters for explicit mode (they could also be provided indirectly for operational modes) referencing the document containing the best definition, so no need to make further description.
Weekly call on June 14th: AP decided in the view of IETF-114 YANG modification : add Inband (IB) OSNR , Out-of-band (OOB) OSNR , Transmitter polarization dependent power difference X-Y skew Tx output power with transmit disabled: need to clarify the meaning since no definition exists both in the OIF IA and in Open ZR+ MSA documents. AP : NAME : to check internally Looking at ITU-T G.698.2 there are cases in which at one application code corresponds 2 line-coding. This would be a problem for IW e.g. in case operational mode is used for transponder (same application code but possible different line coding, no interworking). Different opinion to solve the problem: a) leave ITU-T to deal with that and put some text raising the point. b) use different operational modes c) define an attribute , specifically a list representing an application code with related line-coding as entries. With this option we should define new identities in YANG to represent the different line-coding applicable to the same application code. Weekly call on June 21st: About the point 3 the preferred solution is a) , so we need to add some text explaining the issue. AP NAME to modify the draft adding the text. AP NAME NAME : to add the parameters in YANG layer0-types-ext , grouping common-explicit For the parameter for which there is no reference , as soon as text definiton is ready it will be provided in github (see AP NAME
shouldn't this be a decimal value ? unit is missing Originally posted by NAME in URL
Weekly call March 8th pIco-sec is the usual unit. Having integer is acceptable (positive). uint32 can be fine.
Looks good to me

Discussion:
A YANG Data Model for Layer 0 Types <del> draft-ietf-ccamp-rfc9093-bis-01 </del> <ins> draft-ietf-ccamp-rfc9093-bis-02 </ins> Abstract

Wavelength Division Multiplexing (DWDM) networks RFC7698 ITU- T_G.694.1. <del> [Editors' Note]: This is the introduction from draft-ietf-ccamp- layer0-types-ext-01, to be reconciled with the introduction from RFC9093 above YANG RFC7950 is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols such as NETCONF RFC6241.  The YANG language supports a small set of built-in data types and provides mechanisms to derive other types from the built-in types. This document introduces a collection of common data types derived from the built-in YANG data types.  The derived types and groupings are designed to be the common types applicable for modeling Traffic Engineering (TE) features as well as non-TE features (e.g., physical network configuration aspect) for Layer 0 optical networks in model(s) defined outside of this document. </del> This document adds new type definitions to the YANG modules and obsoletes RFC9093.  For further details, see the revision statements of the YANG module in yang-code or the summary in changes-bis. <ins> The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC8342. </ins> 1.1. Refer to RFC7446 and RFC7581 for the key terms used in this document, and the terminology for describing YANG data models can be found in RFC7950. <del> The YANG data model in this document conforms to the Network Management Datastore Architecture defined in RFC8342. </del> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in

5. <del> IANA has assigned new URIs from the "IETF XML Registry" RFC3688 as follows: </del> <ins> For the following URI in the "IETF XML Registry" RFC3688, IANA has updated the reference field to refer to this document: </ins> <del> This document registers the following YANG module in the "YANG Module Names" registry RFC7950. </del> <ins> This document also adds an updated YANG module to the "YANG Module Names" registry RFC7950: </ins> <del> [Editors' Note] Check the IANA considerations in other bis documents </del> <ins> RFC Editor Note: Please replace XXXX with the RFC number assigned to this document. </ins>