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

[Kristian Larsson <[e-mail]>]

I have seen use case examples for how device level YANG modeled configuration would be sent around in TMF payloads, so while TMF 640/641 are service level, I think there are ideas by some to go even closer to devices. That said, I think the more universal view is that TMF is more service focused, so that too should perhaps be our starting point in this. I think it’s a good starting point, in particular when considering things like the IETF L3VPN service model and other IETF or proprietary service models. I think these service models are great - they’re on the network level and largely concerned with solving things that exist on the network level. Thus mapping in IETF YANG SM models to TMF seems like the natural fit to me - if nothing else, the starting point. The way I see this as more of a generic and high level data model mapping, which we can largely drive in a model-driven fashion, means that we should be able to translate many models without having to specify all the details, just the broad strokes. Thus, if someone wants to attempt to translate device YANG models into TMF payloads, I suppose that would be possible using the same techniques.

Practically speaking, one part of this is translating YANG to JSON-schema. Carl Moberg (founder of Tail-F NCS / Cisco NSO) wrote a plugin for this, https://github.com/cmoberg/pyang-json-schema-plugin, so there is some precedence here. As a WG I think we should standardize the mapping though, since there are some choices. JSON-schema doesn’t understand the content of YANG or concepts like “service” - TMF on the other hand does care about what is a “service” and so for our YANG to TMF mapping, we need to specify where we have services. Like previously mentioned, I think this can be done by pointing out YANG paths. So hopefully, we could end up with a very small set of input parameters to control a model-driven translation of YANG into OpenAPI / JSON-schema that could run directly on existing RESTCONF interfaces of network automation systems!

Would love to see what you can share around BBF interface.

Kind regards,
   Kristian.

> On 4 Jun 2025, at 00:34, Brad Peters <[e-mail]> wrote:
> 
> Hi Kristian,
> Your position is the exact same position we reached in TMF regarding the integration being more of a data model mapping exercise and then how to address the RPCs and the TMF API functions. The position below articulates this well. The ultimate question was enabling most of this programmatically as possible. There are a lot of TMF Open APIs but I am not aware of any that are actual device level APIs. APIs such as TMF640/641 are Service Level and APIs in the 'Resource' layer such as TMF664 Resource Function Activation Management are a management function rather than device level. 
> 
> I'll go back through what we did for the BBF interface and see if I can share that. 
> 
> https://www.tmforum.org/oda/open-apis/directory
> 
> 
> Cheers.
> 
> 
> Brad
> 
> 
> From: Kristian Larsson <[e-mail] <mailto:[e-mail]>>
> Sent: Monday, 2 June 2025 6:39 PM
> To: Brad Peters <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [onions] [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]
>  
> EXTERNAL SENDER – Be cautious opening Links and Attachments
> 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.
> 
> 
> On 28 May 2025, at 11:36, Brad Peters <bradpeters=[e-mail] <mailto:bradpeters=[e-mail]>> wrote:
> 
> Hi Thomas,
> 
> TR313 was the attempt to try and provide guidance to the TMF IT teams regarding the current state of networks and to broaden the horizon of TMF to enable easier integration for Operators between the Service Layer and the Resource Layer. From NEMOPS I think there was also a paper from DT if I recall correctly asking for a similar topic. The objective was to attempt to gain traction with the Open API team to interwork across standard bodies and examine the most practical mechanisms available to achieve the goal. 
> 
> From that regard it appears to have achieved a level of understanding that perhaps the network resource layer may have changed over the last 32 years since X731 or M.3010 was published. Moving forward to M.3041 and the collapse of the EMS/NMS and OSS layers to Service based and network data analytics M.3080 (Smart Operations and AI enhanced telecom operation) changes many aspects. 
> 
> I agree there is a long way to go, but it's a start. I'll have a look at your references as I get time this week. Thanks for the background. 
> 
> I'll try and find out if there is anything that TMF is covering in DTW on the topic.
> 
> 
> Cheers.
> 
> 
> Brad 
> 
> 
> From: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Sent: Wednesday, 28 May 2025 3:27 PM
> To: bradpeters=[e-mail] <mailto:bradpeters=[e-mail]> <bradpeters=[e-mail] <mailto:bradpeters=[e-mail]>>;[e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Cc: [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]
>  
> EXTERNAL SENDER – Be cautious opening Links and Attachments
> Dear Brad,
>  
> I think our universes just collided 😊
>  
> I have been working with my TMF colleagues exactly last week on the translation between resource, service TMF API's and the YANG data models at IETF. Specifically on resource and service state management wherehttps://www.itu.int/rec/T-REC-X.731-199201-I/en appears to be the binding standard between TMF and IETF.
>  
> Starting point at IETF appears to be https://datatracker.ietf.org/doc/html/rfc4268. Looking at oper and admin status in ietf-interfaces and ietf-hardware, we already see gaps. Where ietf-hardware is complete, ietf-interfaces misses some state. On service level, looking athttps://datatracker.ietf.org/doc/html/rfc8969#section-5.2 and follow the reference to https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-10, looking at https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-10#section-5 looking at the vn-state-type identities we see another discrepancy. Further more when you see how draft-ietf-teas-actn-vn-yang document evolved after revision -10 where traffic engineering focus took over from best effort routing. Same discussion as in IETF NMOP on SIMAP.
>  
> I stopped there for a moment and will continue to investigate into lifecylehttps://datatracker.ietf.org/doc/html/rfc8969#section-4.1. The point on TR313 is very relevant. Thanks for sharing! I cross read today morning and see it relevant to what I am currently doing. However, it appears to scratch only the surfaces. We need to close those gaps.
>  
> And the answer to your question: YES! You are not the only one and I think onions might be the place to do that.
>  
> Best wishes
> Thomas
>  
>  
> https://datatracker.ietf.org/doc/html/rfc8343#section-3
>  
>    module: ietf-interfaces
>      +--rw interfaces
>         +--rw interface* [name]
>            +--rw name                        string
>            +--ro admin-status                enumeration {if-mib}?
>            +--ro oper-status                 enumeration
>            +--ro last-change?                yang:date-and-time
>  
>          leaf admin-status {
>            if-feature if-mib;
>            type enumeration {
>              enum up {
>                value 1;
>                description
>                  "Ready to pass packets.";
>              }
>              enum down {
>                value 2;
>                description
>                  "Not ready to pass packets and not in some test mode.";
>              }
>              enum testing {
>                value 3;
>                description
>                  "In some test mode.";
>              }
>            }
>            mandatory true;
>            status deprecated;
>            description
>              "The desired state of the interface.
>  
>               This leaf has the same read semantics as ifAdminStatus.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifAdminStatus";
>          }
>  
>          leaf oper-status {
>            type enumeration {
>              enum up {
>                value 1;
>                description
>                  "Ready to pass packets.";
>              }
>              enum down {
>                value 2;
>                description
>                  "The interface does not pass any packets.";
>              }
>              enum testing {
>                value 3;
>                description
>                  "In some test mode.  No operational packets can
>                   be passed.";
>              }
>              enum unknown {
>                value 4;
>                description
>                  "Status cannot be determined for some reason.";
>              }
>              enum dormant {
>                value 5;
>                description
>                  "Waiting for some external event.";
>              }
>              enum not-present {
>                value 6;
>                description
>                  "Some component (typically hardware) is missing.";
>              }
>              enum lower-layer-down {
>                value 7;
>                description
>                  "Down due to state of lower-layer interface(s).";
>              }
>            }
>            mandatory true;
>            status deprecated;
>            description
>              "The current operational state of the interface.
>  
>               This leaf has the same semantics as ifOperStatus.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifOperStatus";
>          }
>  
>          leaf last-change {
>            type yang:date-and-time;
>            status deprecated;
>            description
>              "The time the interface entered its current operational
>               state.  If the current state was entered prior to the
>               last re-initialization of the local network management
>               subsystem, then this node is not present.";
>            reference
>              "RFC 2863: The Interfaces Group MIB - ifLastChange";
>          }
>  
>  
> https://datatracker.ietf.org/doc/html/rfc8348#section-3
>  
>    module: ietf-hardware
>      +--rw hardware
>         +--ro last-change?   yang:date-and-time
>         +--rw component* [name]
>            +--rw state {hardware-state}?
>            |  +--ro state-last-changed?   yang:date-and-time
>            |  +--rw admin-state?          admin-state
>            |  +--ro oper-state?           oper-state
>            |  +--ro usage-state?          usage-state
>            |  +--ro alarm-state?          alarm-state
>            |  +--ro standby-state?        standby-state
>  
>         container state {
>           if-feature hardware-state;
>           description
>             "State-related nodes";
>           reference
>             "RFC 4268: Entity State MIB";
>  
>           leaf state-last-changed {
>             type yang:date-and-time;
>             config false;
>             description
>               "The date and time when the value of any of the
>                admin-state, oper-state, usage-state, alarm-state, or
>                standby-state changed for this component.
>  
>                If there has been no change since the last
>                re-initialization of the local system, this node
>                contains the date and time of local system
>                initialization.  If there has been no change since the
>                component was added to the local system, this node
>                contains the date and time of the insertion.";
>             reference
>               "RFC 4268: Entity State MIB - entStateLastChanged";
>           }
>  
>           leaf admin-state {
>             type admin-state;
>             description
>               "The administrative state for this component.
>  
>                This node refers to a component's administrative
>                permission to service both other components within its
>                containment hierarchy as well other users of its
>                services defined by means outside the scope of this
>                module.
>  
>                Some components exhibit only a subset of the remaining
>                administrative state values.  Some components cannot be
>                locked; hence, this node exhibits only the 'unlocked'
>                state.  Other components cannot be shut down gracefully;
>                hence, this node does not exhibit the 'shutting-down'
>                state.";
>             reference
>               "RFC 4268: Entity State MIB - entStateAdmin";
>           }
>  
>           leaf oper-state {
>             type oper-state;
>             config false;
>             description
>               "The operational state for this component.
>  
>                Note that this node does not follow the administrative
>                state.  An administrative state of 'down' does not
>                predict an operational state of 'disabled'.
>                Note that some implementations may not be able to
>                accurately report oper-state while the admin-state node
>                has a value other than 'unlocked'.  In these cases, this
>                node MUST have a value of 'unknown'.";
>             reference
>               "RFC 4268: Entity State MIB - entStateOper";
>           }
>  
>           leaf usage-state {
>             type usage-state;
>             config false;
>             description
>               "The usage state for this component.
>  
>                This node refers to a component's ability to service
>                more components in a containment hierarchy.
>  
>                Some components will exhibit only a subset of the usage
>                state values.  Components that are unable to ever
>                service any components within a containment hierarchy
>                will always have a usage state of 'busy'.  In some
>                cases, a component will be able to support only one
>                other component within its containment hierarchy and
>                will therefore only exhibit values of 'idle' and
>                'busy'.";
>             reference
>               "RFC 4268: Entity State MIB - entStateUsage";
>           }
>  
>           leaf alarm-state {
>             type alarm-state;
>             config false;
>             description
>               "The alarm state for this component.  It does not
>                include the alarms raised on child components within its
>                containment hierarchy.";
>             reference
>               "RFC 4268: Entity State MIB - entStateAlarm";
>           }
>  
>           leaf standby-state {
>             type standby-state;
>             config false;
>             description
>               "The standby state for this component.
>                Some components will exhibit only a subset of the
>                remaining standby state values.  If this component
>                cannot operate in a standby role, the value of this node
>                will always be 'providing-service'.";
>             reference
>               "RFC 4268: Entity State MIB - entStateStandby";
>           }
>         }
>  
> https://datatracker.ietf.org/doc/html/draft-ietf-teas-actn-vn-yang-10#section-5
>      /* Identity VN State*/
>  
>      identity vn-state-type {
>        description
>          "Base identity for VN state";
>      }
>  
>      identity vn-state-up {
>        base vn-state-type;
>        description
>          "VN state up";
>      }
>  
>      identity vn-state-down {
>        base vn-state-type;
>        description
>          "VN state down";
>      }
>  
>  
>  
>  
> Thomas Graf
> ____________________________________________________________________________
> Distinguished Network Engineer
> Network Analytics Architect
> Telefon [phone]
> Mobile   [phone]
> [e-mail] <mailto:[e-mail]>
> ____________________________________________________________________________
> Swisscom (Schweiz) AG
> IT, Network & Infrastructure
> Datacenter Functions
> Binzring 17
> 8045 Zürich
> www.swisscom.com <http://www.swisscom.com/>
> Postadresse:
> Binzring 17
> 8045 Zürich
> 
>  
> From: Brad Peters <bradpeters=[e-mail] <mailto:bradpeters=[e-mail]>>
> Sent: Tuesday, May 27, 2025 11:27 PM
> To: Chongfeng Xie <[e-mail] <mailto:[e-mail]>>
> Cc: onions <[e-mail] <mailto:[e-mail]>>
> Subject: [onions] Re: [External] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]
>  
> Be aware: This is an external email.
>  
> Hi ChongFeng,
>  
> TR313 has 3 or 4 sub-documents A, B, C and another that was published last week at the end of the sprint. The last is still an alpha. The focus of TR313 is about the resource layer (TMF Autonomous Network Definition) and the changes occurring within that layer as Network Vendors adopt IETF concepts and items such as, RFC8345 as the Network Model and IETF Service Models. As a result of that, the ultimate exam question that arose from TR313. I was involved in the BBF Inventory to TMF Open API work as part of these discussions.
>  
> There was a presentation on this at the last accelerate meeting. There may be a presentation at DTW. 
>  
> In short, yes, I am very confident of the references.
>  
> Cheers.
>  
> 
> Brad 
>  
> From: Chongfeng Xie <[e-mail] <mailto:[e-mail]>>
> Sent: Tuesday, 27 May 2025 5:06 PM
> To: Brad Peters <[e-mail] <mailto:[e-mail]>>
> Cc: onions <[e-mail] <mailto:[e-mail]>>
> Subject: [External] [onions] Re: YANG based Interface integration with TMF Open APIs [Commercial - Anyone]
>  
> EXTERNAL SENDER – Be cautious opening Links and Attachments
>  
> Hi  Brad,
> I found that TMF TR313 is about " Architecture options for Integration with Resource Technology-Specific Domains v1.0.0", are you sure the TR number for "Evolution of TMF Network as a Service" is right? :-)
>  
> Best regards
> Chongfeng
>  
>  
>  
> >>>>>>>>>>>>>>>>>>>>> 
> Interesting to see that their may be some interest in this topic.
>  
> The ODA Production team in TMF have previously performed a data/rpc mapping between the BBF YANG Inventory interfaces from vendors to the TMF Open API equivalent. The ability to provide an operator friendly integration was identified in TMF TR-313 'Evolution of TMF Network as a Service' to enable greater seamless integration between the Service Layer and Resource Layer. I believe from the TMF April 25 Accelerate meeting that the TMF Open API program has included this item as an objective. There may be some interest in TMF in enabling this capability.
>  
>  
>  
> 
> 
> 
> _______________________________________________
> onions mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>