[onions] Re: YANG APIs (RE: Re: YANG based Interface integration with TMF Open APIs)

[Kristian Larsson <[e-mail]>]

While YANG was built for NETCONF, it isn’t tied to NETCONF. We now have multiple YANG model-driven transports; NETCONF & RESTCONF from the IETF, with multiple flavors of data encoding (XML, JSON, CBOR) and there’s gNMI. So compared to OpenAPI, which only describes HTTP APIs, YANG actually describes things on a higher abstraction level, one where we even abstract over multiple transports.

Practically speaking, our of the “open API specifications” mentioned in the charter, I think this mostly translated to OpenAPI, which is tied to HTTP, and so a schema translation from YANG to OpenAPI is in practice really YANG/RESTCONF (since RESTCONF is the only HTTP based YANG-model driven transport) to OpenAPI. Possibly even further constrained to JSON payloads to make it fit into TMF payloads.

JSON-schema / OpenAPI is in a way more expressive than YANG, we can more finely control the structural schema and how it maps to say JSON payloads. ISTM that any YANG model should be possible to express in JSON-schema / OpenAPI in the sense that a consumer of the OpenAPI spec can generate a correct RESTCONF payload. YANG has richer constraints support, so we will probably loose some data validation precision. With this in mind, I think the pragmatic approach is that we should aim to use existing RESTCONF server interfaces but from clients that can consume open API specifications. That is, we don’t want to define yet another YANG model-driven HTTP transported API - we want to reuse RESTCONF, only define how the rest of the world can communicate with it, in a way that the rest of the cloud / compute world understands.

Kind regards,
    Kristian.



> On 4 Jun 2025, at 12:20, [e-mail] wrote:
> 
> Re-,
>  
> Thanks, Brad.
>  
> “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.” (Brad)   
>  
> Somehow related but not specific to TMF discussion, I received an offline comment about the various API flavors out there and what is denoted by YANG API (is this a REST API, RESTCONF API, etc.?). I hear this confusion. This may be something we need some clarity on and/or at least highlight the intended use in the context of ONIONS. So far, the proposed charter includes the following:
>  
> ==
> ONIONS will also develop recommendations for operationalizing YANG-based APIs (YANG2API). This involves investigating and defining the components required to programmatically transform YANG modules into open API specifications
> ==
>  
> Cheers,
> Med
>  
> De : Brad Peters <bradpeters=[e-mail] <mailto:bradpeters=[e-mail]>>
> Envoyé : mercredi 4 juin 2025 11:53
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail] <mailto:[e-mail]>>; Chongfeng Xie <[e-mail] <mailto:[e-mail]>>; Kristian Larsson <[e-mail] <mailto:[e-mail]>>
> Cc : Thomas.Graf <[e-mail] <mailto:[e-mail]>>; onions <[e-mail] <mailto:[e-mail]>>
> Objet : [onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]
>  
>  
> 
> 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] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, 4 June 2025 7:29 PM
> To: Chongfeng Xie <[e-mail] <mailto:[e-mail]>>; Kristian Larsson <[e-mail] <mailto:[e-mail]>>; Brad Peters <[e-mail] <mailto:[e-mail]>>
> Cc: Thomas.Graf <[e-mail] <mailto:[e-mail]>>; onions <[e-mail] <mailto:[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] <mailto:[e-mail]>>
> Envoyé : mercredi 4 juin 2025 11:07
> À : Kristian Larsson <[e-mail] <mailto:[e-mail]>>; Brad Peters <bradpeters=[e-mail] <mailto:bradpeters=[e-mail]>>
> Cc : Thomas.Graf <[e-mail] <mailto:[e-mail]>>; onions <[e-mail] <mailto:[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.
>  
> ____________________________________________________________________________________________________________
> 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.
> _______________________________________________
> onions mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>