Re: [Teas] Example of model and modules designed for augmentation

Italo Busi <Italo.Busi@huawei.com> Mon, 25 July 2022 19:40 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B914C14F6E7 for <teas@ietfa.amsl.com>; Mon, 25 Jul 2022 12:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 cxhDN4NoFyNT for <teas@ietfa.amsl.com>; Mon, 25 Jul 2022 12:40:54 -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 74359C14F743 for <teas@ietf.org>; Mon, 25 Jul 2022 12:40:54 -0700 (PDT)
Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Ls9JV4z0Yz67bMY; Tue, 26 Jul 2022 03:36:10 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 25 Jul 2022 21:40:50 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2375.024; Mon, 25 Jul 2022 21:40:50 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: Dhruv Dhody <dhruv.ietf@gmail.com>, Lou Berger <lberger@labn.net>
CC: "Rokui, Reza (Nokia - CA/Ottawa)" <reza.rokui@nokia.com>, TEAS WG <teas@ietf.org>
Thread-Topic: [Teas] Example of model and modules designed for augmentation
Thread-Index: AQHYoFksqK2GylMKo0iYPsrjCljJpK2PeOQg
Date: Mon, 25 Jul 2022 19:40:50 +0000
Message-ID: <051d3c8d20e34cd29c353f11ca908c75@huawei.com>
References: <14b29f37-1114-14c0-f021-d12b6ed0bd87@labn.net> <CAB75xn6MDHi+n+2dGNdiqqF_vW+BsaoFzzwgggvdbw39wc_UqQ@mail.gmail.com>
In-Reply-To: <CAB75xn6MDHi+n+2dGNdiqqF_vW+BsaoFzzwgggvdbw39wc_UqQ@mail.gmail.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.208.191]
Content-Type: multipart/alternative; boundary="_000_051d3c8d20e34cd29c353f11ca908c75huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/msSHR72be8zXH1Prg9qGicywPAw>
Subject: Re: [Teas] Example of model and modules designed for augmentation
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2022 19:40:59 -0000

Hi Dhruv,

What is the design objective of being able to “allow new attributes to added without updating YANG model”?

IMHO, updating a YANG model (either with a new revision or with an augmentation) is the best way to add attributes in an interoperable way since this allows the server to inform the client that new attributes have been added and the client to know which servers support or do not support the new attributes

Moreover, updating a YANG model provides a YANG formal definition for the new attributes such as the name, type, range (when applicable), measurement unit (when applicable), …

My 2 cents

Italo

From: Dhruv Dhody <dhruv.ietf@gmail.com>
Sent: lunedì 25 luglio 2022 18:36
To: Lou Berger <lberger@labn.net>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <reza.rokui@nokia.com>; TEAS WG <teas@ietf.org>
Subject: Re: [Teas] Example of model and modules designed for augmentation

Hi Lou,

There were 2 seperate questions on that slide, but with the "opaque" example, the usecase proposed to us was for a way to add "new" attributes via pure configuration in the current model itself without the need for any augmentation.

Issue: To maintain the technology agnostic nature of the YANG model we use
1. A pair of (identity, value (string)) to support many attributes;
• a common practice, for instance different metric-types use a common leaf metric-value of uint64 (RFC8776).
2. Support for “opaque” attributes that can be configured without an identity
• This allow new attributes to added without updating YANG model
Concern: Using a string instead of an explicit type in YANG there could be interoperability issues. The use of opaque attributes that are not defined in YANG adds to this issue.

We need inputs from the WG if that is a valid usecase and the correct approach.

Thanks!
Dhruv

On Mon, Jul 25, 2022 at 9:23 PM Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> wrote:
Reza,

In the session you asked for an example of a model (and modules) that
have been designed with technology specific augmentation in mind.  For
an example, take a look at
https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-30 --
search for augment...

Lou

_______________________________________________
Teas mailing list
Teas@ietf.org<mailto:Teas@ietf.org>
https://www.ietf.org/mailman/listinfo/teas