Re: [Netconf] netconf-binary-encoding comments
Qin Wu <bill.wu@huawei.com> Tue, 10 July 2018 00:52 UTC
Return-Path: <bill.wu@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 D68F1130DD6 for <netconf@ietfa.amsl.com>; Mon, 9 Jul 2018 17:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 0ZVpF0EK-5JF for <netconf@ietfa.amsl.com>; Mon, 9 Jul 2018 17:52:53 -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 CD2FE127148 for <netconf@ietf.org>; Mon, 9 Jul 2018 17:52:52 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B732FD37834EC; Tue, 10 Jul 2018 01:52:49 +0100 (IST)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.382.0; Tue, 10 Jul 2018 01:52:50 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.13]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0382.000; Tue, 10 Jul 2018 08:52:43 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Mahesh Jethanandani <mjethanandani@gmail.com>, Balazs Lengyel <balazs.lengyel@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [Netconf] netconf-binary-encoding comments
Thread-Index: AQHUFHIPJkzJWXW1BE+UQ4og/X05xqSARWmAgAAQm4CABerygIAA04cAgACPYUA=
Date: Tue, 10 Jul 2018 00:52:43 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA9AEFA124@nkgeml513-mbx.china.huawei.com>
References: <14395e68-eb71-7766-d4d2-4de0ea67681f@ericsson.com> <CABCOCHRJM5vTgTXcNircjcn6DCqK5fzW3E2rjMM6sb3A3Edz_g@mail.gmail.com> <AB085A45-5498-45A1-8AED-19C86D9298CF@juniper.net> <aea00c41-0e68-1fad-df5f-ba2df19c7b31@ericsson.com> <FAF2C7CA-AA25-48F8-ADC1-E58B0A15F9B5@gmail.com>
In-Reply-To: <FAF2C7CA-AA25-48F8-ADC1-E58B0A15F9B5@gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.244]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9AEFA124nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/ggcPurWOtpXtg0BIY_sFwNi33Bw>
Subject: Re: [Netconf] netconf-binary-encoding comments
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Network Configuration WG mailing 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, 10 Jul 2018 00:52:57 -0000
发件人: Netconf [mailto:netconf-bounces@ietf.org] 代表 Mahesh Jethanandani 发送时间: 2018年7月10日 8:06 收件人: Balazs Lengyel 抄送: netconf@ietf.org 主题: Re: [Netconf] netconf-binary-encoding comments On Jul 9, 2018, at 4:28 AM, Balazs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote: Efficiency is mostly interesting for yang-push data and not so much for <edit-config> <edit-data> <get-config> <get-data>. I would generally agree that it is not as interesting for <edit-config> or <get-config>. But we have seen instances of <get-data> where the data set being returned can be rather large, e.g. BGP route entries, where encoding of the data would have helped. [Qin]: Another complimentary way to improve NETCONF efficiency is to fragment large size data in the RPC message into data chunk in multiple RPC messages, we see this proposal being cooked for quite a long time, Surprisingly not see any progress on it. But the question is, do we want to be selective in what we encode? Would it not be easier/simpler for all transaction to be in a single form of encoding? However we are more interested in dynamic-subscriptions then in configured subscriptions. Eegards Balazs On 7/5/2018 7:06 PM, Kent Watsen wrote: > When I brought up this issue 5 years ago there was zero interest in improving > the efficiency of NETCONF. Maybe YANG Push will change that POV. I agree that there is little appetite to improve the efficiency of configuration-oriented workflows. Monitoring, for which notifications supports in a big way, have a strong push for efficiency. I think the primary question is if this efficiency must be realizable for NC/RC based subscriptions, or if the efficiency can come from the use of more suitable transports (e.g., gRPC), that can be defined by future "notif" drafts? If we were only interested in such efficiency for configured subscriptions, then I think a "notif" draft to define the transport would be relatively easy. If such efficiency is also needed for dynamic subscriptions, then it seems like something along the lines of what binary-encoding draft proposes might be needed. Is there a need for efficiency for any other workflow? What about for RPCs that are executed often (e.g., polling) or return very large responses? Does we care about making these use cases more efficient too, or are we primarily only interested in just making notifications efficient? Kent On 7/5/18, 12:07 PM, "Netconf on behalf of Andy Bierman" <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org> on behalf ofandy@yumaworks.com<mailto:andy@yumaworks.com>> wrote: Hi, I think the first-order issue is for the WG to decide if there is a problem to be solved by this WG, and if so, what is the problem scope. Details like the SID assignments for rpc, rpc-reply, etc do not really impact that decision. When I brought up this issue 5 years ago there was zero interest in improving the efficiency of NETCONF. Maybe YANG Push will change that POV. https://tools.ietf.org/html/draft-bierman-netconf-efficiency-extensions-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbierman-2Dnetconf-2Defficiency-2Dextensions-2D00&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oAFOh8ZwuiodqCiPKKq5-n9X4-VYRoFJXIfDMi8vvJs&s=rPGpbkoE7L63ymXNzHmAKazwljYuJVs3pa2Pf1arT-A&e=> I think this draft should focus on the protocol mechanisms and not define any media types. Definitions of GPB and other formats are not trivial and need their own RFCs. Andy On Thu, Jul 5, 2018 at 8:07 AM, Balazs Lengyel <balazs.lengyel@ericsson.com<mailto:balazs.lengyel@ericsson.com>> wrote: Hello, Is this applicable for Restconf? Would a Restconf binary encoding be interesting? Chapter 2) - A more detailed explanation of which parts are encoded would be good. What is the top XML element that will be encoded? <rpc>, <RPC-reply>, <RPC-error>, <notification> ? Just referencing a figure in another draft is not enough. - SHOULD, SHALL or SHALL NOT a client server declare support for the XML encoding? Is that always implicit? State it. 4.2) Shouldn't we also have a JSON encoding here? I would think that all encodings need some official reference, defining how they are used with YANG: RFC, web link Is the Thrift and gpb encoding trivial or is it described somewhere or do we need an RFC about it? Please state whichever is the case. regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs..Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com> _______________________________________________ Netconf mailing list Netconf@ietf.org<mailto:Netconf@ietf.org> https://www.ietf.org/mailman/listinfo/netconf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=oAFOh8ZwuiodqCiPKKq5-n9X4-VYRoFJXIfDMi8vvJs&s=g9t4wEhl67_O_ZmVRrFI1qv3g4UdY2tUiwYOV3Xny0o&e=> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com<mailto:Balazs.Lengyel@ericsson.com> _______________________________________________ Netconf mailing list Netconf@ietf.org<mailto:Netconf@ietf.org> https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>
- Re: [Netconf] netconf-binary-encoding comments Eric Voit (evoit)
- Re: [Netconf] netconf-binary-encoding comments Andy Bierman
- Re: [Netconf] netconf-binary-encoding comments Henk Birkholz
- [Netconf] netconf-binary-encoding comments Balazs Lengyel
- Re: [Netconf] netconf-binary-encoding comments Kent Watsen
- Re: [Netconf] netconf-binary-encoding comments Mahesh Jethanandani
- Re: [Netconf] netconf-binary-encoding comments Qin Wu
- Re: [Netconf] netconf-binary-encoding comments Balazs Lengyel
- Re: [Netconf] netconf-binary-encoding comments Andy Bierman
- Re: [Netconf] netconf-binary-encoding comments Juergen Schoenwaelder
- Re: [Netconf] netconf-binary-encoding comments Andy Bierman
- Re: [Netconf] netconf-binary-encoding comments Robert Wilton
- Re: [Netconf] netconf-binary-encoding comments Kent Watsen
- Re: [Netconf] netconf-binary-encoding comments Qin Wu
- Re: [Netconf] netconf-binary-encoding comments Kent Watsen
- Re: [Netconf] netconf-binary-encoding comments Andy Bierman
- Re: [Netconf] netconf-binary-encoding comments Juergen Schoenwaelder
- Re: [Netconf] netconf-binary-encoding comments Andy Bierman
- Re: [Netconf] netconf-binary-encoding comments Robert Wilton
- Re: [Netconf] netconf-binary-encoding comments Qin Wu