Draft: draft-ietf-ccamp-rfc9093-bis

Commentary: I - D changes : Minor editorial updates Updated IANA considerations : YANG changes : Added 400 G attributes : Changed frequency fraction digits : - Added units for      - delay : Change the authors of the I - D and YANG model :      :  belotti 
 The below definitions should be changed as the accuracy (   ) 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 . " ; } typedef frequency - ghz { type decimal64 { fraction - digits 3 ; } units GHz ; description " The DWDM frequency in GHz , e.g. , .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 : 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 :  : 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  : urn : ietf : params : xml : ns :  : 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 ,    Operations Manager 
 I think Amanda is right and we should update the IANA sections as she suggests 
 The original authors of  - types have been completed deleted and disappeared from the draft . We need to add again the 4 original authors of  - 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 in 
 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 . 
  This was finally published yesterday . 
 Thanks a lot Sergio ! Best Regards ,  [ ]    Engineer Cisco Photonics   via   , 48 C - Vimercate ( MB ) Italy < mailto : : +39 039 Mobile : +39 335 Fax : +39 039 
 Thanks   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 400 G with OFEC is relevant to the interface and   ( also 100 G , 200 G , 300 G FlexO with OFEC ) 
 Feedback from a meeting held on Thursday late afternoon : attendees : G.Galimberti , Esther Le Rouzic ,   ,   ,   There is a common agreement that the model is already suitable for any pluggable , no needs to have a specific model to cover 400 G 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  specs on the optical parameters and payload . Either OpenZR+ and  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   . 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 .  ( 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  has the same additional parameters of OpenZR+ OpenROADM specs support OTN but in a different form factor : CFP-2 DCO or other . 
 AP : 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 modification : add Inband ( IB ) OSNR , Out - of - band ( OOB ) OSNR ,  polarization dependent power difference X - Y skew 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 : : to check internally 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 to modify the draft adding the text . AP : 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 
 should n't this be a decimal value ? unit is missing Originally posted by in 
 Weekly call March 8th pIco - sec is the usual unit . Having integer is acceptable ( positive ) .  can be fine . 
 Looks good to me
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.
This document registers the following YANG module in the "YANG Module
Names" registry RFC7950.