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

[Benoit Claise <[e-mail]>]

Hi Brad,


On 6/13/2025 12:56 AM, Brad Peters wrote:
> HI Benoit,
> It was just the way that I interpreted the response. However, it is 
> good to see that my interpretation was incorrect.
>
> This has been a multi-decade discussion on network versus IT 
> boundaries and ownership in many Telcos. Personally, I look for what 
> is required to achieve the business value outcome.
>
> Sorry if my response caused frustration/concern.
Don't worry. No frustration or not even a concern on my side. :-)
It's always good to have discussions, to clarify the definitions, 
problem statements, and the points of view.

Regards, Benoit
>
> Cheers.
>
> *
> *
>
> *Brad*
>
> ------------------------------------------------------------------------
> *From:* Benoit Claise <benoit.claise=[e-mail]>
> *Sent:* Wednesday, 11 June 2025 12:32 AM
> *To:* Brad Peters <[e-mail]>; Vance Shipley 
> <[e-mail]>; Kristian Larsson <[e-mail]>
> *Cc:* [e-mail] <[e-mail]>; 
> [e-mail] <[e-mail]>; [e-mail] 
> <[e-mail]>
> *Subject:* Re: [External] [onions] Re: YANG based Interface 
> integration with TMF Open APIs [Commercial - Anyone]
>
> *EXTERNAL SENDER – Be cautious opening Links and Attachments*
>
> Hi Brad,
>
> Obviously.
>
> I wonder: what makes you believe, from my email below, that I want to 
> impose YANG (or any domain-specific language) everywhere?
> If I work on knowledge graph, this is exactly because it doesn't make 
> sense to translate, let's IPFIX to YANG, or BMP to YANG.
>
> Regards, Benoit
>
> On 6/10/2025 9:07 AM, Brad Peters wrote:
>> Hi Benoit,
>>
>> I don't believe a single language or data model will dominate every 
>> environment. Different domains require their own domain-specific 
>> languages, as described in classic Domain-Driven Design. Within each 
>> domain, a shared language and understanding enable efficient 
>> communication and service delivery.
>> Problems arise when domains are forced to adopt each other's 
>> vocabulary and models. This leads to inefficient, costly, and slow 
>> design cycles, as teams repeatedly reinterpret requirements. These 
>> challenges often occur because there is no common framework bridging 
>> the domains.
>> For example, expecting IT professionals—who are comfortable with JSON 
>> and integration tasks—to master YANG and its specific syntax is 
>> unrealistic. Their preference is to use familiar tools and 
>> principles, which can lead to calls for network domains to abandon 
>> YANG in favour of IT standards. However, tightly coupling static HTTP 
>> APIs to specific data models creates rework and slows integration 
>> whenever changes occur, further increasing costs.
>> To encourage adoption and avoid making operators act as both 
>> developers and mediators, it's crucial to respect domain boundaries 
>> and avoid forcing a single solution across different areas.
>>
>> This is a hard topic, which is why many simply choose to avoid it and 
>> leave it to an operator to solve.....hard issues that impact 
>> operators choice of vendor, impact vendor sales, impact revenue 
>> margins, you would expect that there would be some interest on how to 
>> enable these capabilities.
>>
>>
>> Cheers.
>>
>> *
>> *
>>
>> *Brad *
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Benoit Claise <benoit.claise=[e-mail]> 
>> <mailto:benoit.claise=[e-mail]>
>> *Sent:* Tuesday, 10 June 2025 7:48 AM
>> *To:* Vance Shipley <[e-mail]> 
>> <mailto:[e-mail]>; Kristian Larsson <[e-mail]> 
>> <mailto:[e-mail]>
>> *Cc:* Brad Peters <[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]> <[e-mail]> <mailto:[e-mail]>
>> *Subject:* [External] [onions] Re: YANG based Interface integration 
>> with TMF Open APIs
>>
>> *EXTERNAL SENDER – Be cautious opening Links and Attachments*
>>
>> Dear all,
>>
>> Here is what I believe the best ONIONS outcomes could be:
>>     1. YANG2API tooling
>>     2. making sure all the IETF network & service YANG models work 
>> together
>>     3. The TMF/IETF mapping (which is under specified in the proposed 
>> charter text now)
>>
>> We know for at least a decade that this mapping (3.) is required.  
>> All operators face the CFS to RFS mapping issues & OSS/BSS mapping 
>> issues.
>> Even if the work has been very much needed, I never wanted to be 
>> involved in this cross SDO coordination because:
>>     1. TMF is a kind of top down approach (here is the architecture, 
>> the abstraction, the top APIs ... fill the gaps), while the IETF is a 
>> bottom up approach (starting with the protocol and devices 
>> config/oper data). I believe more in a bottom approach, exposing the 
>> configuration and operational capabilities northbound (to a 
>> controller, a service, a CFS, an OSS/BSS, you name it)
>>     2. YANG at the IETF has already its challenges, which needed to 
>> be fixed before the TMF/IETF mapping. ONIONS is a step in the right 
>> direction (see point 2 above)
>>     3. It's a huge task to try to steer one SDO, it's a huge huge 
>> task to try to coordinate two SDOs (coming from two different angles)
>>
>> However, we all know that one day we will have to fill the gaps. Why 
>> not now in ONIONS, if there is enough energy?
>> See inline.
>>
>>
>> On 6/6/2025 6:06 AM, Vance Shipley wrote:
>>> On Thu, Jun 5, 2025 at 8:11 PM Kristian Larsson<[e-mail]> <mailto:[e-mail]> wrote:
>>>> Feel free to enlighten me, but I believe that while the TMF APIs might enable mapping the network in whatever detail required, it doesn’t actually model any details of the network at any level. It is left as an exercise for the network operator.
>>> True, there is no "L3VPN" API, or anything like that. There are domain
>>> (P/S/R) specific APIs for Catalog, Inventory, Ordering, Activation,
>>> etc.. Everything fits together cohesively by applying the patterns
>>> consistently. In the Resource domain an L3VPN would be described by a
>>> Resource Function Specification and instantiated as a Resource
>>> Function. So we don't create an L3VPN Ordering API, etc.. we just use
>>> the Specification with the generic APIs (e.g. TMF652 Resource Order,
>>> TMF664 Resource Function Activation, etc.).
>>>
>>> I am greatly sympathetic with the lament of "It is left as an exercise
>>> for the network operator". I have been lobbying within TM Forum, as a
>>> contributing member, for them to publish Service/Resource
>>> Specifications, as JSON objects, for common use case examples. If not
>>> normative at least an informative asset would provide a chance of
>>> reducing the replicated integration costs incurred by each network
>>> operator and provide a decent chance of interoperable implementations,
>>> which is otherwise zero.
>> This is the crux of issue.
>> See above "TMF is a kind of top down approach (here is the 
>> architecture, the abstraction, the top APIs ... fill the gaps), while 
>> the IETF is a bottom up approach (starting with the protocol and 
>> devices config/oper data).". If the industry is unable to determine 
>> easy-enough mappings, then the industry (IETF & TMF) at large is 
>> doing something wrong, and something will have to change.
>> Not everything can be solved by tooling btw.
>>>> The IETF YANG models, for device and for services, already have the actual content modeled. It’s been a long and painstaking process that’s taken years to produce those models. I want to leverage that for these TMF interfaces so we can quickly make progress.
>>> Agreed. I see the process conceptually as:
>>>      1) map a YANG data model to an information model
>>>      2) map that information model to the TM Forum information model (SID)
>>>      3) map that onto applicable TM Forum Open APIs
>>> I documented that process for 3GPP NRMs in IG1217:
>>> https://www.tmforum.org/resources/reference/ig1217-resource-inventory-of-3gpp-nrm-for-service-assurance-v1-0-0/ <https://www.tmforum.org/resources/reference/ig1217-resource-inventory-of-3gpp-nrm-for-service-assurance-v1-0-0/>
>> I really hope that there is a better way than to go DM => IM => IM 
>> mappings => DM. If an IM had all the info needed for an 
>> implementation, this would be called a DM and we would not be losing 
>> information in the translation. Please, please, no UML... ;-)
>> If this is the best process, I fear for a success output. I would be 
>> happy to stand corrected though. I investigated Papyrus yeeaaarss ago 
>> and was not convinced.
>> Back to the ONIONS charter, this would might be a nice exercise, for 
>> a joint work between SDOs (TMF, IETF, and BBF?), if there is cross 
>> SDO energy.Regards, Benoit
>>>> It would be good if you and others with TMF knowledge can guide where best to map IETF service models, like L3VPN, into TMF as resources or services.
>>> I will be pleased to contribute to that effort.
>>>
>>>> Yes, and I’m suggesting that we drive the production of those service / resource specifications in a model-driven fashion from the YANG models with a minimal set of extra parameters.
>>> I suggest we work on the conceptual mapping and once agreed codify
>>> that in tooling.
>>>
>>> --
>>> Vance Shipley, SigScale
>>>
>>> _______________________________________________
>>> onions mailing list [e-mail] <mailto:[e-mail]>
>>> To unsubscribe send an email [e-mail] <mailto:[e-mail]>
>>
>>
>
>
>