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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
