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

[Brad Peters <[e-mail]>]

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]>
Sent: Monday, 2 June 2025 6:39 PM
To: Brad Peters <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[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]> 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 where https://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 at https://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]>