[onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]

[Brad Peters <[e-mail]>]

I agree with Med in that how TMF addresses a request is up to TMF. I do know while progressing TR313 there was discussions in initiating a Liaison request with IETF for this exact same topic and pretty much a similar solution as Kristian proposed.

With regards to the APIs there is typically a decomposition from what is referred to as Customer Facing Service (CFS) to one or many Resource Facing Services (RFS) that ultimately are intended to interface to Network Systems/Controllers to create Network Services. As Kristian implies, for those Operators that use TMF, this means that the Operator needs to perform the Integration between what is the TMF API and what is the YANG based API from a Controller/EMS/NMS.

The objective in TR313 development was how to programmatically perform this as much as possible through data mapping and the RPC/functions of the API. If this could be done it would make Operators lives easier and would accelerate adoption of YANG based interfaces in many Operators.

In short, a Liaison request to TMF could enable acceleration and potentially re-invigorate the discussion.


Cheers.


Brad

________________________________
From: [e-mail] <[e-mail]>
Sent: Wednesday, 4 June 2025 7:29 PM
To: Chongfeng Xie <[e-mail]>; Kristian Larsson <[e-mail]>; Brad Peters <[e-mail]>
Cc: Thomas.Graf <[e-mail]>; onions <[e-mail]>
Subject: RE: [onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs


EXTERNAL SENDER – Be cautious opening Links and Attachments

Hi Chongfeng,



I don’t think that we need to get into internals of how TMF works.



The proposed Charter includes sending LSes as a first milestone to align the expectations we have to effectively collaborate on these matters.



Cheers,

Med



De : Chongfeng Xie <[e-mail]>
Envoyé : mercredi 4 juin 2025 11:07
À : Kristian Larsson <[e-mail]>; Brad Peters <bradpeters=[e-mail]>
Cc : Thomas.Graf <[e-mail]>; onions <[e-mail]>
Objet : [onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]



Hi Brad, Kristian, Thomas & onions,



The point of "Integrating YANG-Based Interfaces with TMF Open APIs" is indeed a promising direction worth exploring.

As I’m not very familiar with TMF’s operational processes, I have a question regarding cross-SDO collaboration. To my understanding, TMF mainly focuses on promoting collaboration and standardization in IT systems—such as ordering and billing—and the APIs defined by OpenAPI are mainly used between modules within IT systems, they rarely addressing network capabilities in the past, or at least they haven't done much in this area.   In contrast, APIs derived from YANG modules on the network side will be consumed by user or service systems, making them a new API type within TMF.  In addition, since TMF operates through project workstreams, would this initiative require to setup a dedicated project workstream?

Maybe this is a very basic question, but I hope to receive feedback. Thanks.



Best regards

Chongfeng



From: Kristian Larsson<mailto:[e-mail]>

Date: 2025-06-02 16:39

To: Brad Peters<mailto:bradpeters=[e-mail]>

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

Subject: [onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]

Hi Brad, Thomas, Chongfeng & onions,



I (together with Ian & Kris) put together the NEMOPS paper that among other things surfaced this need for TMF / IETF YANG interop that we’ve seen within DT (DT is heavily invested in TMF - as you know, there is a gap to the network where everything is YANG). I am by no means a TMF expert and I should probably read up on TR313 and others. I do know a thing or two about YANG and declarative data modeling etc in general. It seems to me that the TMF (primarily 640 & 641 but others are in the same vein) are mostly concerned with meta-questions and very general modeling. The IETF on the other hand is focused on concrete network device and network service models. I think we have the chance to marry the two into something quite elegant. I imagine that we can define a high level model-driven approach to make YANG modeled data available in TMF APIs.



I don’t think it’s so much about admin-state, oper-state or other particular attributes, like what https://www.itu.int/rec/T-REC-X.731-199201-I/en goes on to describe. I think we are looking for a more generic data schema level translation and mapping. That said, such specific mappings could perhaps be used to in a more general setting.



TMF uses OpenAPI and allows embedding specific JSON-schemas for the content payload. I think we can reasonably translate YANG to JSON-schema and embed it in TMF envelopes but it requires a bit more thinking to make an idiomatic mapping. YANG is centered on data trees, like the config in a system is conceptually one large “XML document”. TMF is a bit more chopped up with a more native modeling of service instances etc. We need to carefully think through how these are best mapped.



Ideally, I’m thinking we can express through simple rules how IETF YANG models can be mapped into say a TMF service (or resource or product). I.e. that we do not need to manually define how hundreds of YANG leafs are mapped into TMF but rather we can say that in the L3VPN service model, the /sites path gets mapped to a TMF service,  then everything below that subtree we translate YANG to JSON-schema model-driven style.



I’m not sure how you see things. Are you looking to bridge TMF into more of device level YANG things, or are you looking to interconnect on a service level, like L3VPN SM?



Kind regards,

   Kristian.



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