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

Andy Bierman <andy@yumaworks.com> Wed, 26 August 2020 17:29 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 80FF63A18A4 for <netconf@ietfa.amsl.com>; Wed, 26 Aug 2020 10:29:13 -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 PiSK8CcK5LWQ for <netconf@ietfa.amsl.com>; Wed, 26 Aug 2020 10:29:11 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 120033A18AC for <netconf@ietf.org>; Wed, 26 Aug 2020 10:29:09 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id w14so3305660ljj.4 for <netconf@ietf.org>; Wed, 26 Aug 2020 10:29:09 -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=NDyvoAB//sL6zxSji9TqVVlJyHfus+J2bPLJkByYdD4=; b=KubWB5zaRzQ9ZgxqAKhPGVUX5ianSGv909Mxsmv6bswlzfmAZfRYQkORtfFxuIR09y 5xmW8DJ7Mkx+u2hrSTdrvCnyiLysL/FdqorSjc7RH+7MXfub2kTfm5+eW/YcPqXvvinA 22lMDD1MJPl+yu1u3QEXDENIQiHrn8nNBQDsfj7ZT4I+HUV2Vqulswp4aZGizFW5KuN1 L6hydA8gYHdFz3U4Eo7qHyrozX9/y2dAW1UbLjV3oW4fFjn3vu5UjXsoYxhZtJ2ckU9m +DnxWs5o1zz3NjCBP0VuiT7i/BWCkDcbtDoWnvkolsKYQyLefrWKW/+myfjQ+VqXAr4B 5lwQ==
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=NDyvoAB//sL6zxSji9TqVVlJyHfus+J2bPLJkByYdD4=; b=g64ZSVrYI4brKJ0Y6eDZECjQHmCTr9/jv90gEFe8d0AHnfj21XCgls9EFmMePuj1q7 ub943YXc7hTFjDgeZKKKITPIyvsn9pBpIiA3kQWjalgEwnNGqT+zUZ9uR9jbNML6bkN0 ydyUoyHNXFV/yyLt8PazUwB8dYTQHIf+1x1Q+ljYTEl46eKBB5u2nA2oXCpPc3OtRNJx /Z8bPFfdy26gMJzuKGFc0isOG4soMSSlo62VKzidy/X6pf9IQaTlNE//RfMStEOWfJIJ uFkJnLGgHAZxoS7CnbPdCUCJFibPmvfK3iNBE53vrMqRo7icHO3s0x59lrhkO2sts5mx tRyA==
X-Gm-Message-State: AOAM532tduFQTlnH18qvYYzo+vYmbYFX6oVVfgI3zftLkIvMi61L7eFB A9JTUS/eUK4pUKBqOATT+vMVk0uk9y4A0xDAg35CeA==
X-Google-Smtp-Source: ABdhPJzi63SIZY0FeVLq81oXGm4r5m5wZb0vOuNG8ag54B2SGzIWvO1BsY8CLvYptLIgHoD/NEZTmgUtN4oqUBlvhMM=
X-Received: by 2002:a2e:9dd0:: with SMTP id x16mr7369979ljj.144.1598462947718; Wed, 26 Aug 2020 10:29:07 -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>
In-Reply-To: <c5e76be5eec9490fb6d5246de0ad01b1@huawei.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Wed, 26 Aug 2020 10:28:56 -0700
Message-ID: <CABCOCHR-kFCBfiQjxkLt7bdhvOnv7BHr9hihUjp9M6RRPoeQRA@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="0000000000002f9b6705adcb28a7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/RzuM6_qcedv2ZMFdh6hWjMYS56I>
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: Wed, 26 Aug 2020 17:29:14 -0000

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



>
>
>
>
> 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.

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.

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


>
>
>
>
> *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
>
>