search

ietf-ccamp-wg / ietf-ccamp-layer0-types-ext-RFC9093-bis

CCAMP WG repository for ietf-layer0-types-ext
3 stars 3 forks source link

Model alignment with 400G-ZR #51

Closed ggrammel closed 2 years ago

ggrammel commented 5 years ago

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

sergiobelotti commented 4 years ago

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

ggalimba56 commented 4 years ago

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.commailto: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 GitHubhttps://github.com/ietf-ccamp-wg/ietf-ccamp-layer0-types-ext/issues/51, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADQWFMEHBOSM27X6JW7FUMDRPA6DVANCNFSM4IGUV6TA.

italobusi commented 4 years ago

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 commented 4 years ago

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 commented 2 years ago

Feedback from a meeting held on Thursday late afternoon: attendees : G.Galimberti, Esther Le Rouzic, D. Beller, I. Busi, S. Belotti

ggalimba56 commented 2 years ago

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

Transmitter Opt. specs

Receiver Opt. specs.

OIF – ZR

3 different Application Codes:

ZR has the same additional parameters of OpenZR+

OpenROADM specs support OTN but in a different form factor: CFP-2 DCO or other.

sergiobelotti commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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)