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

Andy Bierman <andy@yumaworks.com> Tue, 18 August 2020 22:18 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 5C8BC3A0EDF for <netconf@ietfa.amsl.com>; Tue, 18 Aug 2020 15:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham 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 rcg3fThH1b40 for <netconf@ietfa.amsl.com>; Tue, 18 Aug 2020 15:18:37 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 CD5E63A0AE5 for <netconf@ietf.org>; Tue, 18 Aug 2020 15:18:36 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id 140so11034638lfi.5 for <netconf@ietf.org>; Tue, 18 Aug 2020 15:18:36 -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=QatkvoCo0XQfmsI6gg2+WB79+YrszD8axVsPZkl6eW4=; b=WvWgQ2h1eqwwfSErbjLtQ+91rLA8Q4n1wyUImzQE2X508gLDpqF91fKjoyX7poSLMO Dgp6945dkxS1CPd/D6CVDi9x2b+I4PfoZ7dL6XsfN+FlYOUvcbKWKymoVgewQ4mKcPkk wS+sVbHtYZsI/EI/OZdAMZbdz28oRjiIVJYkfrsfqehuOAWQdC4PitBqPGs9a5E9irEk Q8n7lQ431mTbEmtLVExLxCorCRXVfFGG9nr6bhg2GR3brCrSNstdKjPzNXbPMNY9SMBo QXTVX7da+UUwNp8xqQ79u0W71d0muIgxFJEqRdcuUwFBiVcxtPhUoZMmB//LezYdFeLP wIqg==
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=QatkvoCo0XQfmsI6gg2+WB79+YrszD8axVsPZkl6eW4=; b=EAE29nk7fxGBx54qC7L3g0DO6DRxWq/QjM+ys8xKfq8i2f+OHnCFv7xkXRtr0fBNP5 nnZfOgIm3sTEiBg+GIZWUApyGy7+/9Vc2m+sau6wVV8LfA/CyQOfQdBNlOelBeuluzp8 ThEF69Py0ZvkfKoNiXXUbZ3EwL7tuJqeafAVonLzDXec3wDLnEkGgnWbXN+eRTQselel DZS83RKQ6Q8CGFDikW0h08GtVEo3qfGOuB34ZoWgCy8K9CDkvycmgD9/A4rZDUzw6hAg 8DwmQsBXHYHLpz9mMkXWtE4vSPMgpMUu3VY/YMxgIY3eQg0YrEicQ5qJtCamJPHmcCUQ oobg==
X-Gm-Message-State: AOAM531lMorgEAjmbp6zPNYHBGQCQSY2CO/99mJK/4TrEmi0dmNn2qv4 OtJ7Cuyf/p91jKeZXtT1xAHwmhPapuAooc7oqzcoQQ==
X-Google-Smtp-Source: ABdhPJxTTCh028WpBGYXbRrPgc3qrRcS93Jo/j/8f1xyse+9RUOMxU2RdLFbo10S4BQxIeK/G7Bj1jExGpEwqWKOBlU=
X-Received: by 2002:ac2:5338:: with SMTP id f24mr10683820lfh.5.1597789114559; Tue, 18 Aug 2020 15:18:34 -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>
In-Reply-To: <MN2PR11MB4366A4D447677823320BDC96B55C0@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 18 Aug 2020 15:18:22 -0700
Message-ID: <CABCOCHSFitzwFzjbyB7b5TaEMQsBzbzPPnc=5MTE=LFYRgUaBA@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000998bc505ad2e444e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/7GPQ9DsSb6sk9SLzb1UCsZMNU10>
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: Tue, 18 Aug 2020 22:18:45 -0000

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.

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.


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



> Regards,
> Rob
>
>
>

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
>