Model alignment with 400G-ZR

[ggrammel]

400G-ZR is a non-OTN interface. Need to check if the current terminology used covers such interfaces too.

[sergiobelotti]

https://www.oiforum.com/wp-content/uploads/OIF-400ZR-01.0_reduced2.pdf
This was finally published yesterday.

[ggalimba56]

Thanks a lot Sergio ! Best Regards, Gabriele [http://www.cisco.com/swa/i/logo.gif] Gabriele Galimberti Principal Engineer Cisco Photonics Srl Italy via S.Maria Molgora, 48 C 20871 - Vimercate (MB) Italy www.cisco.com/global/IT/<http://www.cisco.com/global/IT/> ggalimbe@cisco.com<mailto:ggalimbe@cisco.com> Phone :+39 039 2091462 Mobile :+39 335 7481947 Fax :+39 039 2092049 From: sergiobelotti <notifications@github.com> Reply to: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <reply@reply.github.com> Date: Wednesday, 29 April 2020 at 16:59 To: ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang <draft-ietf-ccamp-optical-impairment-topology-yang@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang] Model alignment with 400G-ZR (#24) https://www.oiforum.com/wp-content/uploads/OIF-400ZR-01.0_reduced2.pdf This was finally published yesterday. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#51>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADQWFMEHBOSM27X6JW7FUMDRPA6DVANCNFSM4IGUV6TA>.

[italobusi]

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

[ggrammel]

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)

[sergiobelotti]

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.

[ggalimba56]

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.

[sergiobelotti]

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 @ggalimba56 @sergiobelotti : to check internally with optical expert the real impact for topology model

[sergiobelotti]

The same parameters are defined in both OIF-400ZR-01.0 IA March 2020 and Open ZRP specs , and some of the parameters are better defined in the ZR . Moreover I've noticed that almost all the parameters are also considered in OpenROADM MSA specification 5.0.
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.
20210629_open-roadm_msa_specification_ver5.0.xlsx
OIF-400ZR-01.0_reduced2.pdf
openzrplus_1p0.pdf

[sergiobelotti]

Weekly call on June 14th: AP decided in the view of IETF-114

1. YANG modification : add Inband (IB) OSNR , Out-of-band (OOB) OSNR , Transmitter polarization dependent power difference X-Y skew
2. 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 : @ggalimba56 : to check internally
3. 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 @dieterbeller to modify the draft adding the text.
AP @italobusi @sergiobelotti : 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 @ggalimba56)