ADD 100G lambda MSA Types

[oscargdd]

Change Scope

The requested change is to include new PMD types:

• 100G lambda MSA Types: 100G-LR, 100G-FR, 4X100G-LR, 4X100G-FR
  See https://100glambda.com/

• 2X100G-LR4 is also added.

• Pluggables with those PMDs have been found in the live network and were not being properly reported today as the PMD code was missing.

Platform Implementations

• 100G lambda MSA is available at https://100glambda.com/ and is supported by major vendors. Multiple pluggables are in the market following the specifications.

[proberts2022]

Do we want to continue to define new identity refs for all the possible breakouts or should we make this leaf truly the PMD and add a new leaf that is the number of PMD instances supported by the transceiver?
There is no PMD defined in IEEE802.3 that is "4x100GBASE-LR". There is a PMD defined for "100GBASE-LR".
With the number of breakout options coming with QSFP56-DD, QSFP112-DD, OSFP800 and eventually OSFP1600 there will be an explosion of IDENTITY-REFs. I think it would be more efficient if a transceiver supporting 4 x 100GBASE-LR PMDs would have two leaves:
ethernet-pmd ETH_100GBASE_LR
number-of-pmd 4

[oscargdd]

Hi @proberts2022 ,

I agree that it would be much more efficient and closer to the standard to separate the Nx in the PMD types.

I guess the main historical reason for keeping e.g. the NX in the type is that pluggable datasheets usually include that string in the specifications, so it is easy to find and search.

The donwside it that is a much important change than adding a bunch of identity refs and the new field will take some time to get into the implementations.

What to you think @dplore ?

[dplore]

Hi @proberts2022 ,

I agree that it would be much more efficient and closer to the standard to separate the Nx in the PMD types.

I guess the main historical reason for keeping e.g. the NX in the type is that pluggable datasheets usually include that string in the specifications, so it is easy to find and search.

The donwside it that is a much important change than adding a bunch of identity refs and the new field will take some time to get into the implementations.

What to you think @dplore ?

We have TRANSCEIVER_FORM_FACTOR_TYPE which is intended to specify the pluggable module (which may support one or more breakout capabilities). The PMD should probably remain 1:1 with the physical medium specification and breakouts are defined via /components/component/port/breakout-mode. I think this makes sense as breakouts are configurable at runtime and a given transceiver and PMD can support more than one.

So I think we should not have per-breakout identities for the PMDs.

Thoughts?

[proberts2022]

@dplore
I am not sure I understand your response. Are you suggesting

1. the addition of a new leaf for number-of-pmd or
2. indicating the identity refs should cover the breakout (as they do for 4x25G today) or
3. the PMD should specify only one of the interfaces and then the number of PMD can be assumed from the components/component/port/breakout-group?

IMO, the components/component/port/breakout-group is focused on the C2M PMA covering the host interface between the router and the transceiver. In the case of grey optics, for every separate C2M PMA on the host interface, there is one PMD on the media interface. And in this case, the statement that the breakout-groups configuration can also apply to indicate the number of PMD may work. However, for coherent transceivers, there can be breakout configurations for the host interface that the transceiver then multiplexes into one PMD for the media interface. So maybe we leave coherent transceivers as a special case but it would impact (3) above and we would have to add a special note in the leaf description.

[dplore]

@ejbrever @ahsaanyousaf can you comment?

[dplore]

@oscargdd will share link(s) to example transceivers we want to represent in OC to help guide us on how they should be represented in OC.

[oscargdd]

@dplore Please find a couple of examples of pluggables that need to be modeled:
2x100: https://apps.juniper.net/hct/model/?component=QDD-2X100G-LR4
4x100: https://edgeoptic.com/products/juniper/juniper-400g-200g-25g-compatible-transceivers/qdd-4x100g-fr/

[ahsaanyousaf]

This PMD is same as 400GBASE_DR4?

[ahsaanyousaf]

This is same as line 1280?

[ahsaanyousaf]

So there is no standard for this one, should this be called 400GBASE_DR4++?

[dplore]

/gcbrun

@ahsaanyousaf and @proberts2022 can you each provide your opinion of what the PMD assignment should be for these two transceivers?

2x100: https://apps.juniper.net/hct/model/?component=QDD-2X100G-LR4

4x100: https://edgeoptic.com/products/juniper/juniper-400g-200g-25g-compatible-transceivers/qdd-4x100g-fr/

[OpenConfigBot]

No major YANG version changes in commit 58fdf1a

[ahsaanyousaf]

2x100: https://apps.juniper.net/hct/model/?component=QDD-2X100G-LR4
This should be 2X100G_LR4

4x100: https://edgeoptic.com/products/juniper/juniper-400g-200g-25g-compatible-transceivers/qdd-4x100g-fr/
This should be: 400G_DR4

[jsterne]

2x100: https://apps.juniper.net/hct/model/?component=QDD-2X100G-LR4 This should be 2X100G_LR4

4x100: https://edgeoptic.com/products/juniper/juniper-400g-200g-25g-compatible-transceivers/qdd-4x100g-fr/ This should be: 400G_DR4

I thought Peter's proposal was to avoid things like "2x" in the PMD identities. So wouldn't that first one be this?
ethernet-pmd ETH_100GBASE_LR4 (already exists in the identities)
number-of-pmd 2