Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

Tianran Zhou <zhoutianran@huawei.com> Tue, 22 September 2020 02:04 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43123A10DA for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 19:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0HwoyC5IGqY for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 19:04:38 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 061A53A10D8 for <netconf@ietf.org>; Mon, 21 Sep 2020 19:04:38 -0700 (PDT)
Received: from lhreml704-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0C5072209028AB3B628D for <netconf@ietf.org>; Tue, 22 Sep 2020 03:04:36 +0100 (IST)
Received: from nkgeml704-chm.china.huawei.com (10.98.57.158) by lhreml704-chm.china.huawei.com (10.201.108.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 22 Sep 2020 03:04:35 +0100
Received: from nkgeml707-chm.china.huawei.com (10.98.57.157) by nkgeml704-chm.china.huawei.com (10.98.57.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 10:04:33 +0800
Received: from nkgeml707-chm.china.huawei.com ([10.98.57.157]) by nkgeml707-chm.china.huawei.com ([10.98.57.157]) with mapi id 15.01.1913.007; Tue, 22 Sep 2020 10:04:33 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Kent Watsen <kent+ietf@watsen.net>, Andy Bierman <andy@yumaworks.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
Thread-Index: AQHWa3XT/yp90Vv9H0i3R7lOe+hPQ6kxPqwAgAEGkBCAQSaZAIAABOyAgAAGrgCAALMIwA==
Date: Tue, 22 Sep 2020 02:04:32 +0000
Message-ID: <5c058aa40cbf4141b32b19bd53514415@huawei.com>
References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <CABCOCHTP5boMJpCvhjd=Ur9sTr-+Ea0gSzOJnY_YToHGdurhsA@mail.gmail.com> <e7ccc6495dd34c4fae15a1697ccd1af5@huawei.com> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <CABCOCHR9hBn+vYg-Y8qfWd-Vj5qEqcAuGNrq_Xg+fRiiVALkVA@mail.gmail.com> <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com>
In-Reply-To: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.128]
Content-Type: multipart/alternative; boundary="_000_5c058aa40cbf4141b32b19bd53514415huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/bEnWFCJD7EUjZvdBtdCwqSbP7Dk>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 02:04:40 -0000

Thanks Andy for your opinion. And thank Kent for your expansion and further question.
The goal is to allow the client to know if it has received all the data pieces. Furthermore, the client know which publisher failed to send data. Then it depend on the client to do the action, e.g., ignore, require the data one more, …
We just use the generator-id to indicate the publisher, as we find it in ietf-netconf-notification-messages, and it’s very convenient for this usage.
One use case is exactly as Kent mentioned “Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn’t solely rely on source-IP address (assuming unauthenticated push) to designate the publisher”.
It’s also OK for us to use another indicator if the generator-id is not feasible.
“what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card). ”
If necessary, maybe we can extend this mapping in some initial exchanges. To be clear, how do you want to name the publisher?

Thanks,
Tianran

From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Tuesday, September 22, 2020 6:55 AM
To: Andy Bierman <andy@yumaworks.com>
Cc: netconf@ietf.org
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

[As an individual contributor]

The overall approach to the binary push features seems a bit incoherent to me.
I don't see much value in this draft, but no harm either so I do not have an objection
to adoption.  Perhaps there is some debugging value here but since the architecture
really does not define message generators as sub-components of a configured subscription,
a client cannot expect any sort of consistent implementation of this field.

Good point. If I understand you correctly, what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card).  The solution enables the client to partition notifications coming from different publishers, but that is it.  What value does this have to the client, I don’t know.

Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn’t solely rely on source-IP address (assuming unauthenticated push) to designate the publisher?


Can the authors help resolve the value-proposition question here?

K.