Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling

[Gabriele Galimberti <[e-mail]>]

Ciao Daniele,

I proposed dotted line to fade the relationship between the controller and the pluggable.  Drawn like the picture it looks like there is an “ad hoc” interface dedicated to the pluggable.

Point 2.  Looking at the picture the mapping (partial or complete) is in phase two.  Actually, to define the device models (e.g. operational-mode but also the explicit parameters, etc.) we
Have to refer to the data available at the CMIS interface and try to convert those data into Yang model • that is the mapping, now.

Have a nice WE !!

Gabriele Galimberti

Via Melgacciata, 13
20813 – Bovisio Masciago (MB)
Italy

[phone]

Da: Daniele Ceccarelli <[e-mail]>
Data: venerdì 5 aprile 2024 alle ore 17:35
A: Gert Grammel <ggrammel=[e-mail]>, Gabriele Galimberti <[e-mail]>, Sergio Belotti <[e-mail]>, Gert Grammel <[e-mail]>, "[e-mail]" <[e-mail]>
Oggetto: RE: [CCAMP] Optical pluggables - Gap analysis and Data modelling

Sorry for the confusion with the arrows, the image was pasted into the spreadsheet and not editable and I tried my best to draw on it. Moreover I’m missing what is the difference in meaning between solid, thick and dotted lines…is there any?

Just 2 clarifications on Gabriele’s points:

  1.  “To me between the Router and the pluggable (interface C) there is one and only one interface (CMIS).CMIS is out of IETF scope and can just give us the list of parameters to be provisioned and read (alarms, etc.)to / from the Pluggable (what is called “mapping”).

[DC] yes, personally I agree with you. For the moment “phase 2” means that we’re not covering it now in this document. In the next phase if the WG wants to work on it, we will decide if/how to proceed.

  1.  But if the “mapping” is in phase 2, what do we model in phase 1 ?

[DC] I’m not sure I understood what you mean. In phase 1 we focus on the network models of interface A and the device models of interface B. More precisely on the delta between what exists (draft-ietf-ccamp-optical-impairment-topology-yang + draft-ietf-ccamp-dwdm-if-param-yang) and what is missing.





Cheers

Daniele





From: Gert Grammel <ggrammel=[e-mail]>
Sent: Friday, April 5, 2024 10:39 AM
To: Gabriele Galimberti <[e-mail]>; Sergio Belotti (Nokia) <[e-mail]>; Gert Grammel <[e-mail]>; Daniele Ceccarelli (dceccare) <[e-mail]>; [e-mail]
Subject: Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling

Gab, Sergio,

Thanks for clarifying. Whether “dashed” or “thick”, let’s capture the conclusion in the legend: thick arrows represent the models to manage the pluggable.

Best

Gert



Juniper Business Use Only
From: CCAMP <[e-mail]<mailto:[e-mail]>> on behalf of Gabriele Galimberti <[e-mail]<mailto:[e-mail]>>
Date: Friday, 5. April 2024 at 10:17
To: Sergio Belotti (Nokia) <sergio.belotti=[e-mail]<mailto:sergio.belotti=[e-mail]>>, Gert Grammel <ggrammel=[e-mail]<mailto:ggrammel=[e-mail]>>, Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling
[External Email. Be cautious of content]

Hi All,

I agree on Gert comments and Daniele/Sergio answers (except Point 3).

To me between the Router and the pluggable (interface C) there is one and only one interface (CMIS).
CMIS is out of IETF scope and can just give us the list of parameters to be provisioned and read (alarms, etc.)
to / from the Pluggable (what is called “mapping”).
But if the “mapping” is in phase 2, what do we model in phase 1 ?

More, the thick arrows are confusing I’d explain they represent the models to manage the pluggable and I’d change the in dotted lines).

Ciao,
Gab.


Gabriele Galimberti

Via Melgacciata, 13
20813 – Bovisio Masciago (MB)
Italy

[phone]

Da: CCAMP <[e-mail]<mailto:[e-mail]>> per conto di "Sergio Belotti (Nokia)" <sergio.belotti=[e-mail]<mailto:sergio.belotti=[e-mail]>>
Data: giovedì 4 aprile 2024 alle ore 20:41
A: Gert Grammel <ggrammel=[e-mail]<mailto:ggrammel=[e-mail]>>, "Daniele Ceccarelli (dceccare)" <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Oggetto: Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling

Hi Gert,
What Daniele intended to say is :”The thick arrow between the domain controller and the router (interface B) is the device model we should focus on”
Please do not consider “thin arrow” in the middle (rows 18-19) , as I said to you before during the call the thick arrow is on behalf of the thin arrow and the thin arrow directed towards “coherent plu data on host “ block.
Hope this clarify.
Daniele/Italo please comment if I missed something.

Thanks
Sergio

From: CCAMP <[e-mail]<mailto:[e-mail]>> On Behalf Of Gert Grammel
Sent: Thursday, April 4, 2024 7:00 PM
To: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Daniele,


This clarifies a lot. The point where I still struggle is the meaning of the ”thick arrow” related to question 3 (see below).

Best
Gert



Juniper Business Use Only
From: Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>
Date: Thursday, 4. April 2024 at 17:26
To: Gert Grammel <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: RE: Optical pluggables - Gap analysis and Data modelling
[External Email. Be cautious of content]

Hi Gert,

Graphics often help.
Please find my comments in line.

Cheers,
Daniele



Juniper Business Use Only
From: Gert Grammel <ggrammel=[e-mail]<mailto:ggrammel=[e-mail]>>
Sent: Thursday, April 4, 2024 3:16 PM
To: Daniele Ceccarelli (dceccare) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: Optical pluggables - Gap analysis and Data modelling

Daniele,

Sorry for including some graphics in the email but you can find the references there as well. When checking the sheet called “Scope of IETF Pluggable work” in https://docs.google.com/spreadsheets/d/1atqBARO76hzRp5ETHzsOYLsfabHQbulf0AtbVAMV66A/edit - gid=1168079582<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1atqBARO76hzRp5ETHzsOYLsfabHQbulf0AtbVAMV66A/edit*gid=1168079582and__;Iw!!NEt6yMaO-gk!EVBa8k8tijSp_oINJKgpx2Z9DCp5uA4wiCT0zLtASvlT6gvala18koVhxJ-4BoMEKZObv6OOF1MzlPegi9lHT-Vx-MFjEPjE$>, I was wondering if it is accurately describing what this is about.

  1.  It is true that https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang<https://urldefense.com/v3/__https:/github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang__;!!NEt6yMaO-gk!EVBa8k8tijSp_oINJKgpx2Z9DCp5uA4wiCT0zLtASvlT6gvala18koVhxJ-4BoMEKZObv6OOF1MzlPegi9lHT-Vx-L22mRHH$> is a network model but https://datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-param-yang/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-ccamp-dwdm-if-param-yang/__;!!NEt6yMaO-gk!EVBa8k8tijSp_oINJKgpx2Z9DCp5uA4wiCT0zLtASvlT6gvala18koVhxJ-4BoMEKZObv6OOF1MzlPegi9lHT-Vx-MYnGGLD$> that is associated (i.e. same parameter definitions) belongs to a device model. On what basis is the claim that IETF Pluggable Modeling is a Network Model (left picture at bottom)?
[[DC]] What I was trying to say in the new picture that we suggested, is that the pluggable modelling should have a network model part and a device model part. The picture we proposed is meant to replace this one.
[FXBM3m7wAAAABJRU5ErkJggg==]



In the same picture it is also stated that “In context of IETF pluggable modelling, Optical pluggable is **the** device”. That may cause some confusion, https://datatracker.ietf.org/doc/html/rfc6241<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/rfc6241__;!!NEt6yMaO-gk!EVBa8k8tijSp_oINJKgpx2Z9DCp5uA4wiCT0zLtASvlT6gvala18koVhxJ-4BoMEKZObv6OOF1MzlPegi9lHT-Vx-MndYqgX$> states: “A device MUST support at least one NETCONF session and SHOULD support multiple sessions.” Similarly, OpenConfig has a “Device” container (see https://karneliuk.com/wp-content/uploads/2018/07/128_net_01_oc_yang.png<https://urldefense.com/v3/__https:/karneliuk.com/wp-content/uploads/2018/07/128_net_01_oc_yang.png__;!!NEt6yMaO-gk!EVBa8k8tijSp_oINJKgpx2Z9DCp5uA4wiCT0zLtASvlT6gvala18koVhxJ-4BoMEKZObv6OOF1MzlPegi9lHT-Vx-AE27vUa$> that reflects RFC6241.  So for defining the scope it would be clearer to say Optical pluggable is an optical-terminal” (TBC name for further discussion).

[[DC]] Yes, I agree, makes sense.

 [A diagram of a company    Description automatically generated]


  1.  The figure on the right (starting from column J) is similarly confusing. The “thin arrow” between “domain controller” (=netconf client?) points to a single entry point of the host (=device). What is unclear is the “thick arrow” from the domain controller to the “Coherent Plug Data on Host” It would needs further explanation.
[[DC]] You probably missed the legenda on the top left corner. The thin arrow between the domain controller and the router (interface B) is the device model we should focus on, while the internal communication between the router and the pluggable (interface C) is something that should be out of scope of this first phase and deferred to phase 2. I didn’t have a right terminology to identify it, but in other words it should be the CMIS part.
GGR>> from the legend and this response I gather:

  1.  The “thin arrow” on Interface B represents the device model.
  2.  The “thick arrow” on interface C corresponds to OIF-CMIS: (note: only some of those modules are actually coherent or tunable)

This Implementation Agreement (IA) defines the Common Management Interface

Specification (CMIS), which may be used by pluggable or on-board modules, such as

QSFP Double Density (QSFP-DD), OSFP, COBO, QSFP, as well as by existing or future

module developments with host to module management communication based on a

two-wire interface. This IA is targeted for systems manufacturers, system integrators,

and suppliers of CMIS compliant modules.

  1.  What else is represented then by the ”thick arrow” in Interface B that is not 1) nor 2)?

[Dy4xC6fep4r9AAAAAElFTkSuQmCC]

  1.  The “Scope of IETF Plugable Work” (starting from: C46) in the black box is very focussed on IDs. We don’t know yet how exactly things needs to be modeled and the discussion about telemetry/alarms suggest that more than IDs are needed. My suggestion is to swap host-ID and media-ID with “host-properties” and “media-properties” which would be more general and include the use of IDs.
[[DC]] good suggestion, I’m fine with that if it works for everyone.
[NyBJJjzEBJ23mJE24m829p7npI2E5VgKb+CaiaGsExmPcjB0+exGljnVEkwjBIiLFitZyCqs1+ci9Ys3t1y25rzV+OmWBdCAAAiAAAiAAAiAAAiAAAiAAAl2IwP8DvA3uE1V8QscAAAAASUVORK5CYII=]


Cheers

Gert



Juniper Business Use Only
From: CCAMP <[e-mail]<mailto:[e-mail]>> on behalf of Daniele Ceccarelli (dceccare) <dceccare=[e-mail]<mailto:dceccare=[e-mail]>>
Date: Thursday, 4. April 2024 at 11:02
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [CCAMP] Optical pluggables - Gap analysis and Data modelling
[External Email. Be cautious of content]

Hi Reza, all,

Italo, Sergio and I took a first stab at the shared google doc.
Please find a suggested updated of the interfaces picture in the tab “scope of IETF pluggable work).

Here is the link to the doc for easier access to all the working group.

https://docs.google.com/spreadsheets/d/1atqBARO76hzRp5ETHzsOYLsfabHQbulf0AtbVAMV66A/edit#gid=1168079582<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1atqBARO76hzRp5ETHzsOYLsfabHQbulf0AtbVAMV66A/edit*gid=1168079582__;Iw!!NEt6yMaO-gk!A-2RE0vjxtLcarKoC2-v-78aez5lBzvkbPDv2Qf6VTjd12uO_j3GMxqh6GCGRfCtZLL9YuTYEJANfkCplFmtQrw92NulSj-F$>

Thanks
Daniele

From: Rokui, Reza <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, March 31, 2024 9:27 PM
To: CCAMP Working Group <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rokui, Reza <[e-mail]<mailto:[e-mail]>>; Davis, Nigel <[e-mail]<mailto:[e-mail]>>
Subject: Optical pluggables - Gap analysis and Data modelling

All,

I am not able to attend tomorrow’s meeting.
FYI, Nigel and I worked on the attributes last week and it is in much better shape. We plan to do further improvements.
You should be able to access it. Please take a look.

Reza


Sent from my iPhone