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

Andy Bierman <andy@yumaworks.com> Thu, 27 August 2020 19:14 UTC

Return-Path: <andy@yumaworks.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 39D7C3A1227 for <netconf@ietfa.amsl.com>; Thu, 27 Aug 2020 12:14:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 xye6eVOpAZ_y for <netconf@ietfa.amsl.com>; Thu, 27 Aug 2020 12:14:16 -0700 (PDT)
Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7FFA3A1229 for <netconf@ietf.org>; Thu, 27 Aug 2020 12:14:14 -0700 (PDT)
Received: by mail-lf1-x133.google.com with SMTP id s9so3522612lfs.4 for <netconf@ietf.org>; Thu, 27 Aug 2020 12:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G9iXmbdrvZ6c4j8SnW4dt3NLnu/K7BkgGP+iy/1K/2w=; b=rto1m2z8VNGOn13hZcFDtoqOdDM9CbAnIHNBYV55dA/UADVE5d3R4v/vUXUEti2Aen vxhatqPBPjJI+Ptyuj8pkpFtgyjCivj3FQj1byekH6mgxiEaMR2DArviyg5F2licNYnt 5Xtng8NRU/An9GJdF5YESTSXmU6GpruD+eYHBdTx+dlDKVjDA6hBlDpcJqHBFqno3kop hY+1GbMiyl6S9kLAfSZjgrznNbyUKuiVP4477pub1xFxblvhEnSUg7tm+FkqDIgFci06 9r3qDeD0+l5MDwkKJxsau9LiDiwUSmuRGKcF3M1gjh9YJiwtTlspZfs3MrSUIqv/3BBv iVOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G9iXmbdrvZ6c4j8SnW4dt3NLnu/K7BkgGP+iy/1K/2w=; b=p1q91OtMg1eGnwEoiCT33da6zbHy/UB4ioBRfnyZxSDcSMQE3zkkveJ8tJ3QbDy2D/ GbxwSenHZ/+QtE85EanSnTfEL0aIGw4PRnD+Mv8oalI6kelaC0tFq/w4pGLfNog2YFjv pKcUvnR58xlw1P3L+msYKoVZC9a9OdfCLrb9MqxftWy6ltrwrpb3N6Jl1+0aubQ4C1a/ AMVqzDNie86IUykIt3Lz7PnjETOsYB3f7fZKtbI4znw9FpA+y6ZXBnCGhZHnsDd+9rZc bAIi5L7K1E7Gm/tQ8OQcg+H5YmLxAV41Dre1DIepXtzbY59d+MySb+DLsCrgutRIr5Sc u1vw==
X-Gm-Message-State: AOAM5311mTlWWlM3xOBWpwqPurEQlCdM+rAwzwFd0meUwceCk+MyIZIT 3uSad7IcaxVHgQFlKz8MSr0DD9HdM1j6Pwg7PaIdEA==
X-Google-Smtp-Source: ABdhPJwgp8oInTSv7G/nAmiMJCfzWGs/mjkVOVVttxSMaHyIpjywmKPmSjBtgjPiFH4ikUtyUYh9rL4rikNvoNk7AvQ=
X-Received: by 2002:a19:3f87:: with SMTP id m129mr10275917lfa.44.1598555652654; Thu, 27 Aug 2020 12:14:12 -0700 (PDT)
MIME-Version: 1.0
References: <01000173c0b039d4-76bb4e31-9f40-4a5d-bdac-39512c8b4e9d-000000@us-east-1.amazonses.com> <01000173ca90a8d5-78b55d80-3a92-406a-8544-594dbe223735-000000@email.amazonses.com> <MN2PR11MB4366A4D447677823320BDC96B55C0@MN2PR11MB4366.namprd11.prod.outlook.com> <CABCOCHSFitzwFzjbyB7b5TaEMQsBzbzPPnc=5MTE=LFYRgUaBA@mail.gmail.com> <c5e76be5eec9490fb6d5246de0ad01b1@huawei.com> <CABCOCHR-kFCBfiQjxkLt7bdhvOnv7BHr9hihUjp9M6RRPoeQRA@mail.gmail.com> <07b991b1e32347b58ae4ef968cdffc7f@huawei.com>
In-Reply-To: <07b991b1e32347b58ae4ef968cdffc7f@huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 27 Aug 2020 12:14:01 -0700
Message-ID: <CABCOCHRSE9nRE=UNe_yPeAhUVCMFM0w6n9e==QcA-fNiRFJFUA@mail.gmail.com>
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d4a2de05ade0bda0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0B-r_IMYNSw5srBELSrp5EIBMD0>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-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: Thu, 27 Aug 2020 19:14:19 -0000

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

> Hi Andy,
>
>
>
> Thanks for your reply and suggestions.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* Andy Bierman [mailto:andy@yumaworks.com]
> *Sent:* Thursday, August 27, 2020 1:29 AM
> *To:* Tianran Zhou <zhoutianran@huawei.com>
> *Cc:* Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org>rg>;
> netconf@ietf.org
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-udp-notif
>
>
>
>
>
>
>
> On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <zhoutianran@huawei.com>
> wrote:
>
> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Tianran
>
>
>
> *From:* netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy
> Bierman
> *Sent:* Wednesday, August 19, 2020 6:18 AM
> *To:* Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org>
> *Cc:* netconf@ietf.org
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-udp-notif
>
>
>
>
>
>
>
> On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) <rwilton=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> [Also as a contributor]
>
>
>
> My comments are broadly similar to Kent’s.
>
>
>
> I believe that a UDP transport for dataplane telemetry where getting
> accurate fresh data quickly is more important than getting every update.
> This is particularly true if a subsequent notification will cover any lost
> values anyway (e.g. periodic statistics).
>
>
>
>
>
> agreed.
>
> There is also the resync-subscription mechanism to help recover from
> missing data.
>
>
>
> [ztr] Our intention of using UDP is for data that do not care about
> occasional loss. Typically for period data, and new data will anyway came
> and update.
>
> Does the “resync-subscription” mean the retransmission? Here do you want
> to add the “resync-subscription mechanism” when packet loss is detected
> in this draft?
>
>
>
>
>
>
>
> This is explained in RFC 8641
>
>
>
> ZTR> Yes, I looked into RFC8641. It’s the same as what I understand as
> “retransmission”. Two key points on “resync-subscription” from my
> perspective.
>
> 1. “This RPC is supported only for on-change subscriptions previously
> established using an "establish-subscription" RPC.”
>
> 2. “On receipt, a publisher must either (1) accept the request and quickly
> follow with a "push-update" or …”
>
>
>
> So, what’s your suggestion here?
>
> To support this? Or not support this and add text explicitly in the
> document.
>


Nothing to add to this document.
I was just noting that YANG Push does not rely on every push-change-update
notification to be delivered.  The application layer will re-synch by
itself.



>
>
>
> I suspect that having a mechanism to allow for the telemetry data being
> encrypted is probably also important.  If the WG were to adopt a draft
> without this, then as Benoit mentioned, I would have to test the water with
> the IESG to determine whether that would be acceptable.
>
>
>
> I suspect the lack of congestion control might get their attention as well.
>
>
>
> [ztr] Yes, I agree, both security and congestion considerations need to be
> described in the document. We have section 4 for congestion control. Do you
> have any idea on this?
>
>
>
>
>
> no -- I can't solve problems that IETF creates for itself.
>
> I think the draft says something like "do not use this protocol if
> congestion is a concern".
>
>
>
>
>
>
>
> I also note that the draft allows for a GPB encoding of the telemetry
> data, but I’m not aware of any formal standard encoding of YANG data in
> GPB, and there is a choice between whether the GPB encoding is generic for
> all YANG data, or specific GPB encodings are useful for the specific data
> that is being encoded.
>
>
>
>
>
>
>
> I was confused by the same thing.
>
> Is there a YANG schema for a notification element that is used?
>
> Which means the .proto file is hardwired?
>
> If not then how does the receiver know what is sent?
>
> There are some technical issues that can be addressed if the draft is
> adopted.
>
>
>
> [ztr] In this draft we only consider to include a code point to indicate
> the GPB encoding. How to map YANG to GPB is out of the scope of this draft.
>
> In practice, there are several ways in my opinion.
>
> We can map YANG to proto firstly, and the proto actually describes the
> data structure. I think YANG can almost translate to proto 1:1.
>
> We can also develop YANG to GPB directly, just like YANG to XML and JSON.
>
> In brief, the receiver can still know what is sent by YANG.
>
>
>
>
>
>
>
> I don't think the protocol should include placeholders for
> proprietary solutions.
>
> Either leave out GPB completely or support it in an interoperable way.
>
>
>
> ZTR> We have no position on this. If the WG agreed, we would like to leave
> out GPB.
>


What about just adding a 32-bit report-id field to the header
This is enough. Assignment of the IDs is out of scope.



>
>
> More issues:
>
>
>
> This protocol is not usable by servers that stream data instead of
> building an entire response
>
> in memory. With a streaming design the server doesn't know what will be
> sent in advance so
>
> it sure doesn't know the length in advance.  CBOR does a great job of
> supporting both
>
> types of server design.  NETCONF and HTTP support chunking, which is used
> extensively by
>
> streaming servers. This draft should mention streaming and explain why it
> is not supported.
>
>
>
> ZTR> If you mean bit streaming like TCP, I think UDP cannot support this.
> Do you have any pointer on how CBOR can support the streaming. And how
> NETCONF and HTTP support chunking.
>
> In general, I understand this requirement with small memory or partial
> data. But do you have any real case in the context of YANG push? So that we
> can work on an optimal design.
>


I think it is OK to say that a server is expected to build an entire
response
and the length needs to be known in advance, if fragmentation is not
enabled.
A server can stream data OK if UDP fragmentation is enabled. CoAP uses the
Block option
to support streaming.





>
>
> The generic wrappers (like gNMI and YANG notification schema) do not
> handle "anydata" very well at all.
>
> The binary payload becomes mostly JSON.  Only CBOR+SID handles anydata
> efficiently.
>
> The solution (maybe outside the scope of this protocol) should consider
> how YANG anydata
>
> will be transmitted efficiently and converted from anydata to a real
> schema correctly by the receiver.
>
>
>
>
>
>
>
>
>
> Regards,
> Rob
>
>
>
>
>
> Andy
>
>
>
>
>
> Andy
>



Andy


>
>
>
>
>
>
> *From:* netconf <netconf-bounces@ietf.org> *On Behalf Of *Kent Watsen
> *Sent:* 07 August 2020 21:16
> *To:* netconf@ietf.org
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-udp-notif
>
>
>
> [as a contributor]
>
>
>
>
>
>    1) is the problem important for the NETCONF WG to solve?
>
>
>
> I believe that it is important to enable publishers to send notifications
> using a UDP-based transport.   This belief is based on my experience from
> when at Juniper dealing with very high-end firewalls with enormous log
> output.
>
>
>
> I believe that the NETCONF WG is the appropriate WG for this work, having
> defined RFC 8639 (SN), RFC 8640 (NN), and RFC 8650 (RN).
>
>
>
>
>
>    2) is the draft a suitable basis for the work?
>
>
>
> I have read the current version of the draft and find it to be a
> reasonable start.
>
>
>
> Presuming the “receiver-instances” augmentation defined in
> https://tools.ietf.org/html/draft-ietf-netconf-https-notif-04#section-3 takes
> off, the module defined in this draft should be updated to augment into it
> instead.
>
>
>
> I appreciate Section 5 (Applicability) noting that the UDP-transport is
> primarily for the data plane (not the control plane), as it doesn’t matter
> so much if data plane notifications are lost.  This addresses (I think) the
> issue that Rob Shakir raised before:
> https://datatracker.ietf.org/doc/minutes-103-netconf (search for “Rob
> S”).  That said, it is unclear to me how a receiver could configure this
> while, e.g., configuring control plane notifications to be sent via a
> TCP-based transport such as “https-notif”.
>
>
>
>
>
> 3) regarding Juergen’s questions:
>
>
>
>   a) I am willing to substantially review the drafts.
>
>   b) I am willing to contribute to the discussion of any issue.
>
>   c) I do NOT plan to implement the technology defined.
>
>
>
>
>
>
>
> Kent
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>
>