Boundary between Layer 0 and Layer 1

[sergiobelotti]

ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang#58

[sergiobelotti]

This issue will be discussed in the context of flexible grid meeting. We will take it open till there are no feedback form the discussion in the flexible grid context.

[ggrammel]

https://datatracker.ietf.org/doc/rfc1208/ is using the OSI Model as layering criteria but doesn't attach a number to any layer except for layer-0:

Physical Layer: The OSI layer that provides the means to activate and
use physical connections for bit transmission. In plain terms, the
Physical Layer provides the procedures for transferring a single bit
across a Physical Media.

Physical Media: Any means in the physical world for transferring signals between OSI systems. Considered to be outside the OSI Model, and therefore sometimes referred to as "Layer 0." The physical connector to the media can be considered as defining the bottom interface of the Physical Layer, i.e., the bottom of the OSI.

(Source: https://en.wikipedia.org/wiki/OSI_model)
is in line with above and defines bits and symbols as pertaining to Layer-1.

With that definition the split between Layer-0 and Layer-1 would be the bit or symbol pertaining to Layer-1. This would put the following parameters into Layers:
Layer1: FEC, Framing, bitrate, symbol rate ....
Layer0: total RX-power, Signal TX/RX-power, SNR, impairment compensation, frequency, ....

[sergiobelotti]

#2 (comment)
See the link of slides

[ggrammel]

ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang#58 (comment) is a set of valuable slides that puts the L0 boundary at the OTSi termination. https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2019-07-18-itu-t-sg-15-ccamp-ls-on-description-of-otsi-and-network-media-channel-attachment-1.pdf which clarifies "The OTSi, defined in [ITU-T G.959.1], is the signal that is carried between the output of an OTSi modulator and the input of an OTSi demodulator." This all seems to be consistent with https://datatracker.ietf.org/doc/rfc1208/ associating Layer-1 to a bit-stream, which is the input of a modulator and the output of a de-modulator.

[manzoro]

Update the slide present in ietf-ccamp-wg/draft-ietf-ccamp-flexigrid-yang#58 with info on OpenZR+ multiplexing and pointer to OpenZR+ MSA

layer0-boundary-02.pptx

[manzoro]

As per the discussion during the call on June 18, there is a good consensus on the fact that this issue may need a better description and refocus on its original purpose.
Leaving out the possible identification of a management boundary between L0 and L1, the main purpose of this issue is to identify if we need additional type definition to allow a proper identification of the termination point capability/interoperability in the flex/fixed DWDM tunnel model.

While the L0 application-code provide a clear identification of the photonics signal up to the modulation and FEC format, and the L1 ODU multiplexing schema clearly define the OTN payload structure where present, there is a set of adaptation layer and possible inverse multiplexing configuration in the middle that are not described in any model.

So the focus and purpose of this issue is to define any typedef/attribute that may be useful to fill this gap and describe the end point data structure and adaptation that may be present between L1 multiplexing and L0 application-code definition

Reattaching the slide set with updated scenario for ZR and ZR+

layer0-boundary-03.pptx

[sergiobelotti]

weekly call on 09/10/24:
Here the slides we will use today for our call, reviewing a bit what we have done for this issue.
layer0-boundary-08.pptx

[sergiobelotti]

Updated version after the weekly call
layer0-boundary-08-a.pptx

[sergiobelotti]

Weekly call October 15
Attendees: Aihua, Daniele, Esther, Dieter, Gabriele, Italo (partially) , Julien, Roberto, Yuji

We reviewed the basic slides of the deck to give Daniele the essence of the work we have done about L0/L1 issue.
The important question coming form Daniele was how the present version of OI and RFC9093-bis can be considered completed enough to support most of the use cases needed for operator.
Esther commented that in Orange they already have implementation of OI draft and with that , they can support what is needed from their actual needs.
Aihua said that with the present version of the draft we are not able to support use cases of interoperability between muxponder of different versions, and we can use regenerator always at the lowest level (OUT) since we do not have client information when setup a tunnel, and this information is one that should come with the new L1 things to be added .
Roberto raised also the mapping compatibility of client: at the moment we can support optical compatibility with operational model, but we need to manage the client compatibility outside of the model (Esther mentioned “compatibility matrix” kept in the controller).

Basically what Daniele/Esther/Dieter sustain is the risk to loose momentum for the draft publication waiting other months to add the L1 capability, with the risk that other gaps can be raised and again other time would be spent before go for WG LC and publication .
For this reason the plan is :

1. Going ahead with actual version of OI and RFC9093-bis without adding any of the L1 parameters we have discovered to be needed to support some use cases.
2. Send an email to WG, notifying that RFC9093-bis and OI draft are stable and ready for WG LC. There are L1 capabilities that are not considered till now, but them are not essential to support most of the important use cases.
3. Start a new draft (e.g. OI-bis ?) describing the limitations of the first version of OI draft that we are going to overcome introducing the new L1 parameters described in the slide deck. This new draft should provide L1 capabilities that should be also used by wdm-tunnel .
4. Modify wdm-tunnel in agreement with what described in the slide deck and in the new draft.

It is still pending if presenting something or not at the next IETF 121 or just send email notifying the intention but without presenting anything about L1 story.

Feel free to amend/improve what is needed.

Thanks
Sergio
layer0-boundary-14.pptx