Re: [CCAMP] Summary of the CCAMP meeting on Optical Impairment Topology YANG model

[[e-mail]]

Hello



Sorry I have been disconnected and can not reconnect...

Have a nice evening!

Regards



esther



De : MEURIC Julien TGI/OLN
Envoyé : jeudi 26 mars 2020 14:08
À : Italo Busi
Cc : Daniele Ceccarelli; Belotti, Sergio (Nokia - IT/Vimercate); Beller, Dieter (Nokia - DE/Stuttgart); LE ROUZIC Esther TGI/OLN; Griseri, Enrico (Nokia - IT/Vimercate); Kelly, Colin (Nokia - CA/Ottawa); Gabriele Maria Galimberti (ggalimbe); ([e-mail]); Aihua Guo; Fatai Zhang; CCAMP; Zhenghaomian
Objet : Re: Summary of the CCAMP meeting on Optical Impairment Topology YANG model



Ciao Italo,

Please see my input below as [JM].

Thanks,

Julien



On 26/03/2020 12:31, Italo Busi wrote:

   Hi Daniele,



   The answer to your and Dieter's question "where to define the transponders" seems not trivial to me



   At this moment, three different transponder models have been defined in different drafts (for further details see https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-optical-impairment-topology-yang/issues/29)



   I guess that the transponder model should be defined at least in draft e)

   [JM] Agreed




   and in one of the other drafts.

   [JM] Not so sure. Consistency is mandatory, duplication should be avoided. Do you foresee an issue with including ietf-dwdm-if-param-yang on any device/software that has transponder-related information to export?




   Therefore it would be better to have common set(s) of transponder attributes being defined in a common model (such as the layer0-types): which one depends on how we move forward with layer0-types.



   My preference would be to define these attributes in a version 2 of layer0-types.



   It is also not trivial to know which one or which ones of the other drafts need to model the transponder. I think we need to look at some use cases

   [JM] The use cases can help identifying which information is required, I'm not sure it will help us decide how we split our Yang modules.






   When reporting an optical-impairment aware topology, should we also report the capability of the transponders at the MPI?



   Is this the only case where it is required/useful to report the capability of the transponders at the MPI?



   In case of an alien wavelength, should the OLS PNC be informed about the capabilities of the external OTs? Is this information sufficient or should the OLS PNC report the optical impairments at the MPI?

   [JM] These questions are valuable for deployment, but they don't directly drive the answer to the questions above. We need a Yang module to export transponder-related information in a standard way that is fully consistent with the impairment-aware network modeling. There are use cases where using both sets of information is required at the PNC. I see two main options here:
   - the PNC has NETCONF sessions to both the OLS and the transponders, thus can combine them;
   - the transponders and the OLS exchange information using the right extensions to LMP [1] and RSVP-TE [2], and the OLS PNC makes use of it.

   [1] https://tools.ietf.org/html/draft-ietf-ccamp-dwdm-if-lmp
   [2] https://tools.ietf.org/html/draft-meuric-ccamp-tsvmode-signaling

   My complementary 2 cents,

   Julien






   Just my initial 2 cents



   Italo



   Italo Busi

   Principal Optical Transport Network Research Engineer

   Huawei Technologies Co., Ltd.

   Tel : [phone]

   Email : [e-mail]<mailto:[e-mail]>





   This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!



   From: Daniele Ceccarelli [mailto:[e-mail]]
   Sent: martedì 24 marzo 2020 15:08





   Hi,



   I would agree with Italo.

   We deliberately kept the layer0-types draft "on hold" (even if ready to be progressed) just in case we discovered any last minute change required by other ongoing work, but it makes sense to me to progress it along with documents a,b,c,d as a first cluster.

   One thing we need to further understand is to how to split the content among them. I'm referring to e.g. the point raised by Dieter some days back on where to define the transponders.

   Opinions on this aspect?



   BR

   Daniele



   From: Italo Busi <[e-mail]<mailto:[e-mail]>>
   Sent: den 24 mars 2020 10:46





   Sergio, CCAMP WG,



   The proposals are assuming that in the first phase a set of RFCs are published (drafts a, b, c and d, together with layer0-types), to cover the 'spectrum allocation' scenarios.



   Do we all agree with the proposed phasing approach?



   I think it makes a lot of sense since this model is quite mature (there as few WG LC comments that I guess can be easily and quickly addressed) and allows covering many, even if not all, the use cases that I have seen being requested and deployed



   Regarding the versioning issue, I have uploaded on github few slides trying to clarifying the different options:



   https://github.com/ietf-ccamp-wg/draft-ietf-ccamp-layer0-types/files/4374340/versioning-00.pptx



   I have added a third option where two versions of layer0-types modules are developed in parallel with different revision dates



   A fourth option is to follow the guidelines under development by the Versioning DT in Netmod WG but I am not sure how mature they are as well as if they are supported by existing YANG tools



   Italo



   Italo Busi

   Principal Optical Transport Network Research Engineer

   Huawei Technologies Co., Ltd.

   Tel : [phone]

   Email : [e-mail]<mailto:[e-mail]>





   This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!



   From: Belotti, Sergio (Nokia - IT/Vimercate) [mailto:[e-mail]]
   Sent: venerdì 20 marzo 2020 19:07





   During the meeting the major topic been discussed was related to the e-mail exchange regarding [CCAMP] WG last call on draft-ietf-ccamp-wson-yang-23 and in particular the issue raise by Dieter with the mail sent March 10 on , regarding the alignment among the different L0 YANG models with respect ietf-layer0-types.



   These are the list of drafts we need to consider

   a)       ietf-ccamp-wson-yang;

   b)      ietf-ccamp-flexigrid-yang;

   c)       ietf-ccamp-wson-tunnel;

   d)      ietf-ccamp-flexigrid-media-channel-yang;

   e)       ietf-dwdm-if-param-yang;

   f)        ietf-ccamp-optical-impairment-topology-yang



   There are practically two options on the table:

   1)      Go ahead to publish ietf-layer0-types as reference "types" module for the set of drafts addressing "only" specific use cases that basically is  "spectrum allocation" (a,b,c d drafts) , creating in parallel a new ietf-layer0-types-xxx that can be used for ietf-dwdm-if-param-yang and ietf-ccamp-optical-impairment-topology-yang.

   In this solution there is the problem to understand if the use case claimed to be supported is possible without e.g. transpoder information like the ones contained in the e, f drafts.

   2)      Use "versioning" YANG paradigm, this solution permits to move ahead in parallel two version of the same files "types", and v2 will incorporate all the needed update for e and f drafts.



   Before to take any choice, attendees of the call  decided that a careful review of the ietf-layer0-types is needed to understand possible gaps with respect all optical impairments and transponders description .

   Moreover a new issue will be open in the ietf-layer0-types github to report optical impairments related comments/concerns.

   Attached the e-mail exchange I mentioned at the beginning.



   Feel free to amend and add what is missing.



   Thanks

   Sergio



   Sergio Belotti

   Senior System Engineer and Standardization Architect

   IP/Optical Networks, Optics BU

   Nokia

   M: [phone]

   Via Energy Park, 20871 Vimercate (MB) , Italy

   [e-mail]<mailto:[e-mail]>






_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.