[NMOP] Re: SIMAP Issue 102: REQ-BIDIR

Italo Busi <Italo.Busi@huawei.com> Mon, 02 February 2026 10:38 UTC

Return-Path: <Italo.Busi@huawei.com>
X-Original-To: nmop@mail2.ietf.org
Delivered-To: nmop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id ACA8CB08ACF6 for <nmop@mail2.ietf.org>; Mon, 2 Feb 2026 02:38:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Level:
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vafACun30e74 for <nmop@mail2.ietf.org>; Mon, 2 Feb 2026 02:38:12 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256)) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 34220B08ACEF for <nmop@ietf.org>; Mon, 2 Feb 2026 02:38:12 -0800 (PST)
Received: from mail.maildlp.com (unknown [172.18.224.150]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4f4NN8445WzHnHB7; Mon, 2 Feb 2026 18:37:12 +0800 (CST)
Received: from dubpeml500003.china.huawei.com (unknown [7.214.146.145]) by mail.maildlp.com (Postfix) with ESMTPS id C11604056B; Mon, 2 Feb 2026 18:38:09 +0800 (CST)
Received: from dubpeml500004.china.huawei.com (7.214.147.1) by dubpeml500003.china.huawei.com (7.214.146.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 2 Feb 2026 10:38:09 +0000
Received: from dubpeml500004.china.huawei.com ([7.214.147.1]) by dubpeml500004.china.huawei.com ([7.214.147.1]) with mapi id 15.02.1544.011; Mon, 2 Feb 2026 10:38:09 +0000
From: Italo Busi <Italo.Busi@huawei.com>
To: "Benoit@everything-ops.net" <benoit@everything-ops.net>
Thread-Topic: SIMAP Issue 102: REQ-BIDIR
Thread-Index: AQHckgh92s8xRbMCyUqo2fxQxxcG3rVvO91g
Date: Mon, 02 Feb 2026 10:38:09 +0000
Message-ID: <428f0da502384308b8da114376c70d9e@huawei.com>
References: <a7d293e8-ad99-435d-971a-04050d587f1d@everything-ops.net>
In-Reply-To: <a7d293e8-ad99-435d-971a-04050d587f1d@everything-ops.net>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.147.140]
Content-Type: multipart/alternative; boundary="_000_428f0da502384308b8da114376c70d9ehuaweicom_"
MIME-Version: 1.0
Message-ID-Hash: PUB2G7ZE3XYU7RBIRQKMESXJYTEZST3F
X-Message-ID-Hash: PUB2G7ZE3XYU7RBIRQKMESXJYTEZST3F
X-MailFrom: Italo.Busi@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "nmop@ietf.org" <nmop@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [NMOP] Re: SIMAP Issue 102: REQ-BIDIR
List-Id: "Network Management Operations (NMOP) Working Group" <nmop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/nmop/r-FAl4w2WsU-qGWlpkZpkWCwlwA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nmop>
List-Help: <mailto:nmop-request@ietf.org?subject=help>
List-Owner: <mailto:nmop-owner@ietf.org>
List-Post: <mailto:nmop@ietf.org>
List-Subscribe: <mailto:nmop-join@ietf.org>
List-Unsubscribe: <mailto:nmop-leave@ietf.org>

Hi Benoit,

I am fine with the updated text

Thanks, Italo

From: Benoit@everything-ops.net <benoit@everything-ops.net>
Sent: venerdì 30 gennaio 2026 17:50
To: Italo Busi <Italo.Busi@huawei.com>
Cc: nmop@ietf.org
Subject: SIMAP Issue 102: REQ-BIDIR

Italo,

Thanks for your feedback.
Regarding this issue https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/issues/102
REQ-BIDIR
The term "simplified service layer topology" needs further qualification on the "simplification".
I do agree on the requirement to show how a bidirectional link in the client layer (or higher abstraction view) can be supported by two unidirectional links in the server layer (or lower abstraction view).
We must understand that "simplified service layer topology" as the fact that not all SIMAP users/applications want to see the two unidirectional; under some circumstances/for a specific service layer topolgoy, a bidir is sufficient. Even from a pure display point of view, this is a simplified view.
Let's simplify :-) the text

OLD:

 REQ-BIDIR:  SIMAP must provide a mechanism to model bidirectional

      links.  While data flows are unidirectional, the bidirectional

      links are also common in networking.  Examples are Ethernet

      cables, bidirectional SONET rings, socket connection to the

      server, etc.  There is also the requirement for simplified Service

      layer topology, where a link is modeled as bidirectional in order

      to be supported by unidirectional links at the lower layer.
NEW:

 REQ-BIDIR:  SIMAP must provide a mechanism to model bidirectional

      links.  While data flows are unidirectional, the bidirectional

      links are also common in networking.  Examples are Ethernet

      cables, bidirectional SONET rings, socket connection to the

      server, etc., where a link is modeled as bidirectional, which in turn

      might be supported as unidirectional links at the lower layer.





This change is applied via https://github.com/ietf-wg-nmop/draft-ietf-nmop-digital-map-concept/pull/160

Regards, Benoit