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

[Andy Bierman <[e-mail]>]

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou <[e-mail]> wrote:

> Hi Andy,
>
>
>
> Thanks for your reply and suggestions.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* Andy Bierman [mailto:[e-mail]]
> *Sent:* Thursday, August 27, 2020 1:29 AM
> *To:* Tianran Zhou <[e-mail]>
> *Cc:* Rob Wilton (rwilton) <rwilton=[e-mail]>;
> [e-mail]
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-udp-notif
>
>
>
>
>
>
>
> On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <[e-mail]>
> wrote:
>
> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Tianran
>
>
>
> *From:* netconf [mailto:[e-mail]] *On Behalf Of *Andy
> Bierman
> *Sent:* Wednesday, August 19, 2020 6:18 AM
> *To:* Rob Wilton (rwilton) <rwilton=[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [netconf] Adoption-suitability for
> draft-unyte-netconf-udp-notif
>
>
>
>
>
>
>
> On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) <rwilton=
> [e-mail]> 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 <[e-mail]> *On Behalf Of *Kent Watsen
> *Sent:* 07 August 2020 21:16
> *To:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netconf
>
>