[netmod] How to make vendor-specific extension?

yuchaode <yuchaode@huawei.com> Thu, 18 May 2023 06:17 UTC

Return-Path: <yuchaode@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF08C15108D for <netmod@ietfa.amsl.com>; Wed, 17 May 2023 23:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEEYqL6iuRFz for <netmod@ietfa.amsl.com>; Wed, 17 May 2023 23:17:20 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC14C15152F for <netmod@ietf.org>; Wed, 17 May 2023 23:17:19 -0700 (PDT)
Received: from lhrpeml100004.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QMKQh0kzRz67rl5 for <netmod@ietf.org>; Thu, 18 May 2023 14:13:00 +0800 (CST)
Received: from canpemm100001.china.huawei.com (7.192.105.122) by lhrpeml100004.china.huawei.com (7.191.162.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 18 May 2023 07:17:15 +0100
Received: from canpemm500002.china.huawei.com (7.192.104.244) by canpemm100001.china.huawei.com (7.192.105.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Thu, 18 May 2023 14:17:13 +0800
Received: from canpemm500002.china.huawei.com ([7.192.104.244]) by canpemm500002.china.huawei.com ([7.192.104.244]) with mapi id 15.01.2507.023; Thu, 18 May 2023 14:17:13 +0800
From: yuchaode <yuchaode@huawei.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: How to make vendor-specific extension?
Thread-Index: AdmJUFJUDfEs1z7vQYG6BZjRu7xQCA==
Date: Thu, 18 May 2023 06:17:13 +0000
Message-ID: <6e6b6af09eef4214b5cfaf5efd0cc8e5@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.117.46.217]
Content-Type: multipart/alternative; boundary="_000_6e6b6af09eef4214b5cfaf5efd0cc8e5huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Xcm3tF9DAcsEFTMaGoJ9x2u8KxU>
Subject: [netmod] How to make vendor-specific extension?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 May 2023 06:17:24 -0000

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