[netconf] 答复: Which is the better way for vendor-specific extension?

[yuchaode <[e-mail]>]

Hi Jan,

Thanks for your comments. I will send another email to NETMOD mailing list too.
At the same time, I also add an example to explain why the augmentation is a heavy burden for the orchestrator.

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?

B.R.
Chaode
发件人: Jan Lindblad [mailto:[e-mail]]
发送时间: 2023年5月17日 16:54
收件人: yuchaode <[e-mail]>
抄送: [e-mail]
主题: Re: [netconf] Which is the better way for vendor-specific extension?

Chaode,

This question might belong more to the domain of the NETMOD WG, which deals with modeling questions.

You are saying you find the augment mechanism "will be a heavy burden for the orchestrator", but you are not giving any examples or other explanations of why you think so. Then you propose an alternate mechanism with opaque key-value lists. I don't see in what way this would be any less burdensome (except maybe for the implementor, who may be tempted to skip the documentation step). Quite the contrary.

In order for the additional-info mechanism to work, all YANG models would need to include   uses additional-info-grouping;   statements everywhere the modeler could possibly imagine anyone wanting to extend the model. That sounds terribly burdensome to me. Or else, maybe you are suggesting the NETCONF protocol should be changed to allow such key value lists literally everywhere. Maybe that is why you posted to NETCONF?

If you prefer (undocumented, or documented outside of YANG modules) key-value lists in your vendor extensions, you can go right ahead and implement that. Just use augment to add that additional-info-grouping structure anywhere you like. I can't say I'd recommend this approach, however.

Best Regards,
/jan




On 17 May 2023, at 10:25, yuchaode <yuchaode=[e-mail]<mailto:yuchaode=[e-mail]>> wrote:

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.
For example, there is an ietf-example.yang, in which there are three attributes named attr-1, attr-2, attr-3.
Vendor A thinks that these three attributes are not enough, he would like to extend attr-4. He can write a vendor-a-ext.yang to specify this attribute.
So when to retrieve the ietf-example data, for vendor A, he can response with:
{
 “ietf-example:root”: {
“attr-1”: a,
“attr-2”: b,
“attr-3”: c,
“vendor-a-ext:attr-4”: d
  }
}

In multi-vendor scenario, there could be a lot of vendor-specific extension. If the source structure is very complex, the vendor-specific extension could be everywhere, this is messy and will be a heavy burden for the orchestrator.
Is there any suggestion to deal with these flexible vendor-specific extension?

In some traditional protocols, such as CORBA, a fixed name-value pair structure is provided for vendor-specific extension.
For vendor A’s scenario, it can work like below (here I use json format for better comparison):
{
  “root”: {
“attr-1”: a,
“attr-2”: b,
“attr-3”: c,
   “additional-info”: {
“name”: “vendor-a-ext:attr-4”,
“value”: d
}
}
}
So for the orchestrator, it is easy to recognize which part of attributes are standard and which part of attributes are vendor-specific. It will be of great help for their programing.

I remember there used to be a discussion and opposed to introduce this opaque structure, which was said to be harmful for standardization.
But I also found such kinds of experience in openconfig, such like the properties structure in openconfig-platform module.
So, which is a better way for vendor-specific extension?

The above is just my superficial views, welcome to have your comments. Thanks!

B.R.
Chaode
_______________________________________________
netconf mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netconf