[Teas] Name and description for topological elements (was RE: IVY versus RFC8345 going forward)
Italo Busi <Italo.Busi@huawei.com> Wed, 24 July 2024 21:32 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 5BE08C1D5C47; Wed, 24 Jul 2024 14:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 2DeDk179iwit; Wed, 24 Jul 2024 14:32:23 -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 00408C1D4A7F; Wed, 24 Jul 2024 14:32:23 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.31]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WTnHj6FtDz6K5TG; Thu, 25 Jul 2024 05:30:41 +0800 (CST)
Received: from frapeml500005.china.huawei.com (unknown [7.182.85.13]) by mail.maildlp.com (Postfix) with ESMTPS id 3CC38140257; Thu, 25 Jul 2024 05:32:21 +0800 (CST)
Received: from frapeml500007.china.huawei.com (7.182.85.172) by frapeml500005.china.huawei.com (7.182.85.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Wed, 24 Jul 2024 23:32:20 +0200
Received: from frapeml500007.china.huawei.com ([7.182.85.172]) by frapeml500007.china.huawei.com ([7.182.85.172]) with mapi id 15.01.2507.039; Wed, 24 Jul 2024 23:32:20 +0200
From: Italo Busi <Italo.Busi@huawei.com>
To: Olga Havel <olga.havel=40huawei.com@dmarc.ietf.org>, "inventory-yang@ietf.org" <inventory-yang@ietf.org>, "nmop@ietf.org" <nmop@ietf.org>
Thread-Topic: Name and description for topological elements (was RE: IVY versus RFC8345 going forward)
Thread-Index: AdreDmeIc4+jsiyRTFqoF2YRYUOO5A==
Date: Wed, 24 Jul 2024 21:32:20 +0000
Message-ID: <dbd311096c2141a7bd5641230b61f97c@huawei.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.241.254]
Content-Type: multipart/alternative; boundary="_000_dbd311096c2141a7bd5641230b61f97chuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: BEMHVGH66ICHD4QG25GLQJCDMEEA4LJK
X-Message-ID-Hash: BEMHVGH66ICHD4QG25GLQJCDMEEA4LJK
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "teas@ietf.org" <teas@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Name and description for topological elements (was RE: IVY versus RFC8345 going forward)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/VQ2lRJ-23j9MKO0pI1MsKgVsFSw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>
Hi Olga, I am addressing the first of your bullet so I have updated the mail subject for simpler tracking of the discussion I agree with you that having name and description attributes defined in different augmentation modules is a source of confusion especially when these different augmentation models are going to be used together (there will be multiple name attributes, one for each augmentation model, on the same object and it is not clear which one should be used) What do you mean by adding them to the "core topology model"? 1. Adding these attributes in an RFC8345-bis 2. Adding these attributes in a small module augmenting RFC8345 With the first option we are not going to solve the problem by adding a (N+1)-th option to the N which exists today, while causing troubles also to the cases where an augmentation model is used alone. IMHO, this option would make sense if and only if we also deprecate the duplicated definitions in all the augmentation models. The second option is not solving the current problem but it is at least mitigating the issue in the future since new augmentation models shall no longer define name and description attributes and rely on this new augmentation model when used alone or on one of the other augmentation models when used with other augmentation models which already provide the information My 2 cents Thanks, Italo From: Olga Havel <olga.havel=40huawei.com@dmarc.ietf.org> Sent: mercoledì 24 luglio 2024 11:24 To: inventory-yang@ietf.org; nmop@ietf.org Subject: [IVY] IVY versus RFC8345 going forward Hi, I raised 2 things during todays ivy meeting, both of them can be addressed after adoption of the ivy inventory topology draft. In fact both of these comments are more related to RFC8345 than inventory: * Name is added in so many RFC8345 augmentations, maybe we want going forward to do it in more reusable way. Maybe we need name and description to be added to the core topology model. * RFC8345 describes how inventory is related to ietf-network only via augmentation, not connected to ietf-network-topology. We may need to do either one of the following: * In RFC8345 bis we change the descriptions and figures and align the RFC8345 fully with the ivy approach * In inventory topology we add the section that says what is different from the approach as described in RFC8345 I prefer Option 1, please let me know what you think. Best Regards, Olga