discussion points from Gert

[oscargdd]

I keep here for tracking the discussion points

• packet networks are predominantly linked by direct connect fibers and OLS is only a small subset. This draft deals with that subset.
• Optical pluggables exist since >20years, the difference is now that coherent pluggables are way more complex to manage and they are optically interoperable as defined by standards.
• Optical pluggable not only go into routers but also into transponder line-cards of optical systems and OXC.
• Line systems are not controlled by one controller but are typically controlled by vendor specific controllers. Hence at typical IP/MPLS network faces the totality of OLS-systems/subnetworks which involves many O-PSC controllers.
• Optical planning is not always part of the provisioning process. i.e. optical rings can be designed for any-to-any connectivity with 400ZR+ modules. Based on that design, no additional optical planning is needed during the provisioning process as the planning phase has been completed beforehand.

[oscargdd]

• For the first comment, the scenarios in the draft are OK, but the following sections focus mostly on OLS based scenario. Need to dedicate also part of the work for the direct fiber scenarios.
• • The use cases on breakouts need more thought.
• Do we need to spill out "coherent" from title? (To be discussed..)
• Add an scenario showing different line systems connected to the same router? (action point on operators to see the scenario)

[ggrammel]

As discussed in our last call, there are more pluggables coming up using CMIS with programmable AppSel codes; some use coherent technology, others don't. Examples for non-coherent listed below and we expect more to come in future. It would help to control these programmable modules in the same fashion, irrespective of their technology or whether they are connected to a line system or fiber.

1. OSFP 800G-2xFR4 plug has 3 standard AppSels (plus 2*vendor specific ones)
2. non-coherent OSFP-2X400G-VR4-P not only supports 100G per lane AppSel codes (800G-VR8, 400G-VR4, 200G-VR2, 100G-VR1) but also 50G per lane AppSel codes (400G-SR8, 200G-SR4, 100G-SR2, 50G-SR).
3. 800G QSFPDD AOC supports 12 different ApSel code, that allow for 56G PAM4 or 112GPAM4 modulation, also depend on number of datapath, if multiple datapath configured, each independent datapath will have it's own clock domain.
4. 800GBASE-DR8 for example, supports three different AppSel codes, and it can have one, two or eight different datapaths depending on which ApSel code was selected.

[ju7ien]

Shared during September 24th meeting. The comment deserves to be discussed in details. We understand it as "enlarging the scope of work and be more generic", which would be OK; the proposal will get less support if the effort to add specifics about the non-coherent is too large and may delay the outcome. To be tackled (with Gert) in an upcoming call.

[ggrammel]

The challenge is that CMIS is for any kind of pluggable and not specific to coherent. Also programmability is not limited to coherent modules (see https://github.com/oscargdd/draft-poidt-ccamp-actn-poi-pluggable-usecases-gaps/issues/21#issuecomment-2358654631). Moreover PAM is also delivered over line systems and newer modules are programmable too. It might be useful to phrase Use Case descriptions in a technology neutral manner.