Hi Chaode, If the orchestrator have to process all vendor’s extended attributes, I think the two approaches may be the same.
Do you mean it’s more difficult for augmentation approach to parse the payload than approach 2? I don’t think so, orchestrator parse payload according schema, approach 1 using augmentation will be very easy to parse the payload. And I don’t know the approach 2 how to define the key-value pairs extended by vendors, reserving , for example, 10 key-value pairs for vendors? That way is opaque, and the orchestrator doesn’t know the correct meaning. 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 yuchaode 发送时间: 2023年5月18日 14:17 收件人: netmod@ietf.org 主题: [netmod] How to make vendor-specific extension? Hi friends, Since the definition of standard cannot always cover all the attributes of different vendors, vendor-specific extension is necessary to exist. Especially for IETF YANG data model, some of our drafts takes years to release. Vendors cannot wait for all the drafts are released, and their development has to begin with an immature version, and make some extensions based on their owned understanding. When I learned YANG language on my first time, people told me that we can use some vendor-specific YANG models to augment the existing models to make this vendor-specific extension. If a orchestrator needs to coordinate multiple domain controllers who all have their owned extensions, and the source standard YANG data structure is very complex. Because that all the vendors can their owned extensions in any places, from orchestrator’s view, the overall data structure can look like: { "ietf-example:root”: { "attr-1”: a, "attr-2”: b, "attr-3”: c, "vendor-a-ext:attr-4”: d, "vendor-b-ext:attr-5": e, "containter-1": { "attr-6”: f, "attr-7”: g, "attr-8”: h, "vendor-a-ext:attr-9”: i, "vendor-c-ext:attr-10": j, "vendor-d-ext:list-11”: [{ "attr-12”: k, "attr-13”: l }], "list-14": [{ "attr-15”: m, "attr-16”: n, "attr-17”: o, "vendor-a-ext:attr-18”: p, "vendor-c-ext:container-19”: { "attr-20”: q, "attr-21”: r } }] } } } Please note that the attributes start with vendor-*-ext are extended by different vendors. We can see that, the extensions can be happened at any places with any format or structures. The orchestrator need to do a lot of judgement and adaption for these extension. But if we use a fixed name-value pair, we could ask the vendors to extend their extensions in a same place with a same structure. For example, the above data can be changed to: { "ietf-example:root”: { "attr-1”: a, "attr-2”: b, "attr-3”: c, "containter-1": { "attr-6”: f, "attr-7”: g, "attr-8”: h, "list-14": [{ "attr-15”: m, "attr-16”: n, "attr-17”: o, }] }, "additional-info": [ { "name": "vendor-a-ext:attr-4", "value": "d", }, { "name": "vendor-a-ext:attr-9", "value": "i", }, { "name": "vendor-a-ext:attr-18", "value": "p", }, { "name": "vendor-b-ext:attr-5", "value": "e", }, { "name": "vendor-c-ext:attr-10", "value": "j", }, { "name": "vendor-c-ext:attr-20", "value": "q", }, { "name": "vendor-c-ext:attr-21", "value": "r", }, { "name": "vendor-d-ext:attr-12", "value": "k", }, { "name": "vendor-d-ext:attr-13", "value": "l", } ] } } It is very clear that the data except additional-info structure are all from standard. And it is easy for orchestrator to parse the vendor-specific extensions, because they are all following with a generic structure. Maybe it is still needed for the orchestrator to understand the series of name in the additional-info group, vendors’ API document can help for this. I think API documents are both needed in these two approaches. If you agree this is a good approach, but now that a lot of YANG data models have been released, we cannot ask all of them to modify and add this additional-info structure. Can we allow the additional-info structure to be existing by default for YANG data model under the root container, or under every container and list, from YANG language perspective? The above is just my superficial views, welcome to have your comments. Thanks! B.R. Chaode
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod