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

From: Kent Watsen <[email-masked]>
Date: Wed, 5 Aug 2020 22:14:01 +0000

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: UDP-based Transport for Configured Subscriptions
   Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif
   Abstract:

      This document describes an UDP-based notification mechanism to
      collect data from networking devices.  A shim header is proposed to
      facilitate the streaming of data directly from line cards to a
      collector.  The objective is to rely on a lightweight approach to
      allow for higher frequency and better transit performance compared to
      already established notification mechanisms.

In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?

PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs

---

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Aug 2020 20:15:44 +0000

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 10 Aug 2020 12:37:33 -0700

Hi,

I am trying to understand the NETCONF WG plan for UDP transport of
notifications.

The WG was developing a UDP draft already I think, and it was dropped.
https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05

Since the WG dropped this problem and work item already, why should it
reverse that decision
and start over with a new solution?

Andy

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <[email-masked]> wrote:

> PS: this message is itself not an adoption poll, but rather an attempt to
> gauge interest/support for a potential future adoption poll.
>
> NETCONF Chairs
>
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 10 Aug 2020 14:47:14 -0700

Hi Andy,

> On Aug 10, 2020, at 12:37 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I am trying to understand the NETCONF WG plan for UDP transport of notifications.
> 
> https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05 <https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05>

In IETF 103, there was extensive discussion on draft-ietf-netconf-udp-pub-channel, with questions raised about the scope of the draft. In IETF 105 and 106, our guidance (see meeting minutes) was to repurpose the draft for a UDP notification channel, which the WG would then ultimately adopt. This draft satisfies that request. To clarify this further, the datatracker marks the new draft as a replacement for the draft-ietf-netconf-udp-pub-channel.

Mahesh & Kent (as co-chair)

> 
> Since the WG dropped this problem and work item already, why should it reverse that decision
> On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen..net <mailto:[email-masked]>> wrote:
> NETCONF WG,
> 
>    Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif <https://tools.ietf.org/html/draft-unyte-netconf-udp-notif>
>    Abstract:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 11 Aug 2020 02:39:15 +0000

Hi Andy,

Thanks Mahesh for the clarification from the chairs perspective.

And here is my clarification from the co-author perspective.
We implemented the previous solution, and contributed it to IETF.
But we dropped the solution because no customer has interest about this at that time. I do not want to waste the WG time.

We restart the draft because now several operators and customers have real requirements and use cases, and would like to work on this solution.
We reconstructed the solution with inputs, and would like to implement it to align with the changes.
We would also like to share and contribute to the community.

Cheers,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Mahesh Jethanandani
Sent: Tuesday, August 11, 2020 5:47 AM
To: Andy Bierman <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Hi Andy,

On Aug 10, 2020, at 12:37 PM, Andy Bierman <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Andy

On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen..net<mailto:[email-masked]>> wrote:
NETCONF WG,

NETCONF Chairs

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 12 Aug 2020 11:45:42 +0800

Hi WG,

With regard to the 2 questions:

I think the UDP transport for configured subscription is valuable for the NETCONF WG. It's useful in at least two scenarios in carrier network.
One is for core devices with large amount of data to export. The UDP transport together with distributed exporting mechanism could relieve the device work load.
The second is when the collector want to collect data from large amount of devices, e.g., the devices at the edge. The proposed solution can make the collector's life easier.

I've read document. I believe it's a good basis for the working group to continue.

[email-masked] & [email-masked]
 
From: Kent Watsen
Date: 2020-08-06 06:14
To: [email-masked]
Subject: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif
NETCONF WG,

 

 
NETCONF Chairs

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Aug 2020 15:07:47 -0700

On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani <[email-masked]>
wrote:

> In IETF 103, there was extensive discussion on
> draft-ietf-netconf-udp-pub-channel, with questions raised about the scope
> of the draft. In IETF 105 and 106, our guidance (see meeting minutes) was
> to repurpose the draft for a UDP notification channel, which the WG would
> then ultimately adopt. This draft satisfies that request. To clarify this
> further, the datatracker marks the new draft as a replacement for the
> draft-ietf-netconf-udp-pub-channel.
>
>
I support adoption of this draft.
I am willing to work on the document, review it, and implement it.
Hopefully the authors will add an example of a notification in each
encoding soon.

IMO there really should be 1 RFC that combines these documents:

     draft-unyte-netconf-udp-notif
     draft-unyte-netconf-distributed-notif
     draft-ietf-netconf-notification-messages

The single source vs. multi-source distinction does not really require
separate documents.
General one-size-fits-all notification headers are too inefficient to use in
a high performance telemetry system.  Not sure where notification-messages
will ever get used.
IMO these 3 documents could be a good protocol, if combined and focused
correctly.

Andy

> On Wed, Aug 5, 2020 at 3:14 PM Kent Watsen <kent+ietf@watsen..net
> <[email-masked]>> wrote:
>
>> NETCONF WG,
>>

---

From: <[email-masked]>
Date: Sun, 16 Aug 2020 10:26:44 +0000

Hi Mahesh,

Thank you very much for the good summarization.

Hi Andy,

Thank you very much for the feedback. I am happy to hear that you will review the document and consider to implement.

  *   Hopefully the authors will add an example of a notification in each encoding soon.
Sure, Pierre François, one of the co-authors and professor at INSA university and his colleagues already started working on an open-source YANG push library for the receiver (data-collection) to support udp-notif and distributed-notif. We planned to integrate this library into the open-source project pmacct at IETF 109 hackathon to showcase a working receiver with a first vendor implementation. Further, we are in the evaluation on what environment to build an example open-source publisher which can be taken as reference for other implementations.

It would be interesting to understand how we could potentially collaborate. I think the IETF 109 hackathon would be a good place to work and validate each other implementation. As we already were doing with BMP (BGP Monitoring protocol) in previous IETF hackathons.
https://www.ietf.org/proceedings/108/slides/slides-108-grow-ietf-108-hackathon-bmp-00. What do you think?

Best Wishes
Thomas

From: netconf <[email-masked]> On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2020 12:08 AM
To: Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

On Mon, Aug 10, 2020 at 2:47 PM Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Hi,

The WG was developing a UDP draft already I think, and it was dropped.
https://tools.ietf.org/html/draft-ietf-netconf-udp-pub-channel-05<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-netconf-udp-pub-channel-05&data=02%7C01%7CThomas.Graf%40swisscom.com%7C6d61dd2dd3c3422f6c2d08d8409e8fc9%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330397053580529&sdata=6YtbXF3DIp%2BJDhoi9flTQjWN92c6qv%2FT6sXqVRjLwCc%3D&reserved=0>

I support adoption of this draft.
I am willing to work on the document, review it, and implement it.
Hopefully the authors will add an example of a notification in each encoding soon.

The single source vs. multi-source distinction does not really require separate documents.
General one-size-fits-all notification headers are too inefficient to use in
a high performance telemetry system.  Not sure where notification-messages will ever get used.
IMO these 3 documents could be a good protocol, if combined and focused correctly.

Andy

Andy

   Title: UDP-based Transport for Configured Subscriptions
   Link: https://tools.ietf.org/html/draft-unyte-netconf-udp-notif<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-unyte-netconf-udp-notif&data=02%7C01%7CThomas.Graf%40swisscom.com%7C6d61dd2dd3c3422f6c2d08d8409e8fc9%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330397053590475&sdata=m4ogTh90gPL4SVM2tGseQT9j6PY8ufPr5fPfNgvbK0I%3D&reserved=0>
   Abstract:

NETCONF Chairs

_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C6d61dd2dd3c3422f6c2d08d8409e8fc9%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330397053590475&sdata=%2BdVisZkWD%2B9yBiavHLvkYEIwFKwJeOlx7yIu%2BI4gFEU%3D&reserved=0>
_______________________________________________
netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnetconf&data=02%7C01%7CThomas.Graf%40swisscom.com%7C6d61dd2dd3c3422f6c2d08d8409e8fc9%7C364e5b87c1c7420d9beec35d19b557a1%7C1%7C0%7C637330397053600443&sdata=bd3zWWkteoRA01MGWVZWAJM2wyCQH3Gs3ye9HNJ5zlU%3D&reserved=0>

---

From: Tianran Zhou <[email-masked]>
Date: Mon, 17 Aug 2020 03:23:40 +0000

Hi Andy,

Thank you very much for your interest.
The two drafts was one when it first came out.
 draft-unyte-netconf-udp-notif
draft-unyte-netconf-distributed-notif
We split it based on the WG discussion, so that the distributed-notif can also serve the tcp based notif.

Current distributed-notif solution depends on draft-ietf-netconf-notification-messages. But I believe draft-ietf-netconf-notification-messages tries to solve more problems in addition to distributed-notif.

On your suggestion, I think we can work on an profile or applicability, to see how they can work together.

Thanks,
Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Saturday, August 15, 2020 6:08 AM
To: Mahesh Jethanandani <[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Hi,

Andy

Andy

NETCONF Chairs

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 18 Aug 2020 13:42:35 +0000

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

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

Regards,
Rob

From: netconf <[email-masked]> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

[as a contributor]

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

Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 18 Aug 2020 15:18:22 -0700

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) <rwilton=
[email-masked]> wrote:

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

Andy

>
>
> *From:* netconf <[email-masked]> *On Behalf Of *Kent Watsen
> *Sent:* 07 August 2020 21:16
> *To:* [email-masked]
> *Subject:* Re: [netconf] Adoption-suitability for
> 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).
>
>
>
>
>
> 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”.
>
>
>
>
>

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Aug 2020 08:17:50 +0000

Hi Andy,

Please see inline.

Tianran

From: netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]>
Cc: [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

On Tue, Aug 18, 2020 at 6:42 AM Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

[Also as a contributor]

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?

[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?

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.

Regards,
Rob

Andy

From: netconf <[email-masked]<mailto:[email-masked]>> On Behalf Of Kent Watsen
Sent: 07 August 2020 21:16
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

[as a contributor]

Kent

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Aug 2020 08:59:31 +0000

Hi Rob,
Thanks for your comments.
Please see in line.

Tianran
From: netconf [mailto:[email-masked]] On Behalf Of Rob Wilton (rwilton)
Sent: Tuesday, August 18, 2020 9:43 PM
To: Kent Watsen <[email-masked]>; [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Hi,

[Also as a contributor]

[ztr] Yes. So we described this in section 5. Do you want to propose more text?

[ztr] We will work on a draft to describe about the encryption.

[ztr] Just to clarify, this draft only consider a code point to indicate the GPB encoding. With this indication, the receiver knows how to decode the message. YANG to GPB is out of the scope.
What’s your suggestion? Do you suggest us not to include GPB as a encoding?

Regards,
Rob

[as a contributor]

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Aug 2020 10:28:56 -0700

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <[email-masked]> wrote:

> Hi Andy,
>
>
>
> Please see inline.
>
>
>
> Tianran
>
>
>
> *From:* netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Wednesday, August 19, 2020 6:18 AM
> *To:* Rob Wilton (rwilton) <rwilton=[email-masked]>
> *Cc:* [email-masked]
> [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 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".

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

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.

Andy

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Aug 2020 01:50:51 +0000

Hi Andy,

Thanks for your reply and suggestions.

Cheers,
Tianran

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <[email-masked]>
Cc: Rob Wilton (rwilton) <rwilton=[email-masked]>; [email-masked]
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

On Wed, Aug 26, 2020 at 1:17 AM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Please see inline.

Tianran

From: netconf [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Wednesday, August 19, 2020 6:18 AM
To: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

[Also as a contributor]

agreed.

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.

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

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.

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

[as a contributor]

Kent

---

From: Andy Bierman <[email-masked]>
Date: Thu, 27 Aug 2020 12:14:01 -0700

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

> *From:* Andy Bierman [mailto:[email-masked]]
> *Sent:* Thursday, August 27, 2020 1:29 AM
> *To:* Tianran Zhou <[email-masked]>
> *Cc:* Rob Wilton (rwilton) <rwilton=[email-masked]>;
> [email-masked]
> 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.”
>

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.

> ZTR> We have no position on this. If the WG agreed, we would like to leave

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

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

Andy

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 28 Aug 2020 09:01:18 +0000

Hi Andy,

Thanks again for your further comments.

Tianran

Sent: Friday, August 28, 2020 3:14 AM

On Wed, Aug 26, 2020 at 6:50 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Cheers,
Tianran

From: Andy Bierman [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 27, 2020 1:29 AM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: Rob Wilton (rwilton) <rwilton=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-udp-notif

Please see inline.

Tianran

[Also as a contributor]

agreed.

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.

ZTR> Agreed. Thanks.

 ZTR> Sorry, I did not get you on what’s this 32-bit report-id? We have a 4 bit encoding type field, which can support 16 encodings. We can set this as a registry and defer the assignment of GPB.

More issues:

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.

ZTR> Got it. Yes, this draft enables UDP fragmentation which can support data streaming.

Regards,
Rob

Andy

Andy

Andy

[as a contributor]

Kent

---

From: Andy Bierman <[email-masked]>
Date: Mon, 31 Aug 2020 10:39:36 -0700

Hi,

I am still very confused about the content. Not the encoding. That is a
separate issue.
Sec 2, and 3.1 refer to the "subscription-started" notification and
"the NETCONF/RESTCONF notification message".

This text seems to imply that the <notification> element defined in RFC 5277
is used for the content.  But sec. 3.4 mentions bundled notifications so
maybe not.

Usually the application protocol defines the message flows that are
expected.
This document is a transport protocol for an unspecified application.
There is
an assumption that publisher and receiver both know the protocol somehow.
For GDB, they magically know how to distinguish different proto files.

IMO this level of disregard for interoperability is unacceptable for a
standard protocol.

Andy

On Fri, Aug 28, 2020 at 2:01 AM Tianran Zhou <[email-masked]> wrote:

> *Sent:* Friday, August 28, 2020 3:14 AM
>  ZTR> Sorry, I did not get you on what’s this 32-bit report-id? We have a
> 4 bit encoding type field, which can support 16 encodings. We can set this
> as a registry and defer the assignment of GPB.
>
>
>
>
>
>
>
> More issues:
>
>
>