[Teas] Re: IETF120 Digital Map Side Meeting

[[e-mail]]

Hi Olga, all,

Thank you for leading this and for allowing for various groups with different perspectives to discuss and agree on common next steps.

I have one comment about "NMOP preference" and "TEAS preference" mentions. I understand what you intended but procedurally speaking there is no such a thing.

Cheers,
Med

De : Olga Havel <olga.havel=[e-mail]>
Envoyé : jeudi 25 juillet 2024 22:55
À : [e-mail]; [e-mail]
Objet : [Teas] IETF120 Digital Map Side Meeting

Dear NMOP and TEAS,

Thanks for attending the Digital Map Side meeting at IETF120 in Vancouver. The slides are shared on NMOP github:
Misc/side-meetings/ietf-120-sidemeeting-Digital-Map.pdf at main · ietf-wg-nmop/Misc (github.com)<https://github.com/ietf-wg-nmop/Misc/blob/main/side-meetings/ietf-120-sidemeeting-Digital-Map.pdf>

Thanks all for the lively discussion and even without reaching agreement I think it was very valuable discussion.
For refresh, we were discussing between the following 2 approaches:

  1.  Use RFC8345 as a core topology model for the digital map, gaps to be fixed in RFC8345 bis - NMOP preference
  2.  Use RFC8795 as a core model as it already addresses a subset of the gaps identified - TEAS preference

The slides communicate the reasons for 1, but in summary - simplicity + usability

TEAS do agree about both points, their argument is that RFC8795 can be used with profiles in which case a profile could be created for the Digital Map Topology Model. Otherwise, the gaps addressed by TE would be done differently in the bis. Please note that 3 out of 7 gaps were done in TE, 2 of them partially.

My understanding is that even with profiles, the official API definition is still the standard YANG module from RFC8795. The profiles are currently the hack until supported by the YANG. Discovering of profiles and supporting profiles is not yet in YANG/Netconf/Restconf. Italo's proposal is instead of focusing on RFC8345bis and procedural change to focus on adding the profiles programmatically in IETF. Nevertheless, we are still left with the problem is when you create a model that defines attributes that are defined also somewhere else.

Please a reminder for all that the RFC8345 augmentation analysis can be found on
Misc/Digital-Map-Analysis at main · ietf-wg-nmop/Misc (github.com)<https://github.com/ietf-wg-nmop/Misc/tree/main/Digital-Map-Analysis>

We found only 13 out of 52 analyzed files using te, others just need ietf-network and ietf-topology. This is ¼ of the topology augmentations / imports.
Please Italo and other in TEAS, could you review your drafts/RFCs in the spreadsheet and if we categorized them correctly. And please let us know if anything is missing.

Conclusion:
We have different opinions if ietf-network-topology (NMOP) or ietf-te-topology (TEAS) is the best basis for modelling the digital map.

I presented the following proposal, feedback at the meeting was to agree the use case as soon as possible:

     *   2 Hackathons at  IETF 121, agree the use case
     *   Pros / cons of both approaches after hackathons, where we can compare API definitions and API request / response examples
     *   Collect opinions from operators and others

Best Regards,
Olga

____________________________________________________________________________________________________________
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.