[netconf] Re: questions about draft-udp-notif-14

[Andy Bierman <[e-mail]>]

On Thu, Jul 18, 2024 at 8:09 AM <[e-mail]> wrote:

> Dear Andy,
>
>
>
> Thanks a lot for giving us feedback on the implementation of the document.
> This is very much appreciated.
>
>
>
> Before answering your comments, please be aware that we requested and
> received an early transport directorate review
> https://datatracker.ietf.org/doc/review-ietf-netconf-udp-notif-11-tsvart-early-tuexen-2023-11-15/
> with revision -11 of the document. It is worth to review their feedback. We
> requested this feedback because we felt that some of the comments we
> received on the netconf mailing lists prior did not reflect what has been
> discussed and defined in other areas and working groups of the IETF.
>
>
>
> Regarding to "IP fragmentation". I would take
> https://datatracker.ietf.org/doc/html/rfc2460#section-5 as a guidance on
> MSS. 1280 is the minimum for IPv6. 576 for IPv4 networks. However, with the
> introduction of gigabit ethernet, the default MTU in service provider
> networks today is 9160.
>
>
>


This is optional to implement by the publisher.
It is optional to use by the receiver.

So the mandatory-to-implement seems to be a single UDP frame of 64K bytes,
which seems to ignore the text about relying on IP fragmentation.
The application is required to generate updates that fit the client
transport layer needs for each receiver.

IMO this can impact the dataset.
e.g.
  - counters for 1000 interfaces change
  - the dampening-period is 5 seconds
  - the server can report 10 interfaces in one report

It takes 100 separate UDP reports to push the changes.
Does the publisher take 500 seconds to finish this update or does the
dampening-period
not apply, and a burst of 100 reports is sent at once?

Datastore replication updates may not validate in refactored into arbitrary
increments.
There may be use-cases where the hand-crafted 64K report will work fine, but
it also trades some problems for different ones.


Andy





Regarding to "Segmentation option". You are raising two questions. Wherever
> the 15-bit size of the sequent number field
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-4.1
> should be increased or not. TCP defined 32-bit (
> https://datatracker.ietf.org/doc/html/rfc2385#section-4.3) And wherever
> turning off segmentation is a valid option or not. It is clear that JSON or
> XML encoding is not the right encoding for transferring large amount of
> data. For this purpose CBOR has been defined. From my >5 years experience
> with YANG notifications, I usually observe the average message size in
> production networks is between 500 bytes up to 2 Mbytes on small routers
> and large distributed routers combined. Therefore I conclude that
> increasing the sequence number field to 32-bit would not bring added
> benefit. I agree that having segmentation not turned on, is rather a corner
> case when the YANG-Push publisher does not support segmentation. I have
> seen segmentation not supported on network processors and SmartSFPs. But
> even in these cases there was not technical reason not to implement.
> However for the sake of applicability, I suggest to keep segmentation
> optional but have it turned on by default makes perfectly sense. Will
> address in -015.
>
>
>
>     leaf enable-segmentation {
>
>       if-feature segmentation;
>
>       type boolean;
>
>       default false;
>
>       description
>
>         "The switch for the segmentation feature. When disabled, the
>
>         publisher will not allow fragment for a very large data";
>
>     }
>
>
>
> Regarding "Overflow indication". I think this is addressed well in
> https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif#section-5.2
> and in https://www.rfc-editor.org/rfc/rfc8085.html#section-3.2. In case
> there is something missing, please let me know.
>
>
>
> Regarding "Application Layer". Udp-notif is used as transport for
> YANG-Push configured subscriptions as defined in
> https://datatracker.ietf.org/doc/html/rfc8639#section-2.5.
>
>
>
> Regarding "Implementation details". There already many similar alternate
> propriety YANG-Push transport implementations out there. To name two: Cisco
> (
> https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/24xx/telemetry/configuration/guide/b-telemetry-cg-asr9000-24xx/dial-out-telemetry-session-from-router-to-destination.html)
> and Juniper (
> https://www.juniper.net/documentation/us/en/software/junos/interfaces-telemetry/topics/concept/junos-telemetry-interface-oveview.html)
> We have currently 3 vendor implementations of udp-notif. Feedback from
> their implementers where that it is relatively easy to apply due to its
> simplicity.
>
>
>
> Best wishes
>
> Thomas
>
>
>
> *From:* Andy Bierman <[e-mail]>
> *Sent:* Wednesday, July 10, 2024 10:27 AM
> *To:* Netconf <[e-mail]>
> *Subject:* [netconf] questions about draft-udp-notif-14
>
>
>
> *Be aware:* This is an external email.
>
>
>
> Hi,
>
>
>
> I am trying to implement this draft
>
> https://www.ietf.org/archive/id/draft-ietf-netconf-udp-notif-14.html
>
>
>
> General:
>
>
>
> The intended use of this protocol seems to be where a server creates fixed
> size reports
>
> and the server knows the report size. This is difficult if a report
> includes nested
>
> YANG list entries.
>
>
>
> YANG Push is used for multiple purposes, including datastore replication.
>
> Initial or resych payloads can be very large.  Datastore changes are
> subject
>
> to YANG validation so they cannot be refactored into many tiny
> transactions.
>
>
>
> Streaming servers may not know the exact entries or the sizes in advance.
>
>
>
>
>
> 1) IP fragmentation
>
>
>
> Even though a UDP segment is about 64K bytes, the max-segment-size
>
> is the real fragment length. (e.g. about 1200 bytes)
>
>
>
> An implementation of this specification SHOULD NOT rely on IP
> fragmentation by default to carry large messages. An implementation of this
> specification SHOULD either restrict the size of individual messages
> carried over this protocol, or support the segmentation option. The
> implementor or user SHOULD take into account the IP layer header size when
> setting the max-segment-size parameter to avoid fragmentation at the IP
> layer.¶
> <https://www.ietf.org/archive/id/draft-ietf-netconf-udp-notif-14.html#section-4.1-6>
>
> 2) Segmentation option
>
>
>
> Only 32767 segments are allowed for the entire message which is about 40MB
>
> if IP fragmentation is being avoided.
>
>
>
> Segmentation can be disabled by the client on a per-receiver basis.
>
> Each receiver can set its own max-segment-size.
>
> This is difficult and expensive to implement.
>
> Expect that servers will reject complex configurations and clients will
>
> need to read the user documentation (not the RFC) to know what is
> supported.
>
>
>
> If enable-segmentation=false then the server may reject this setting.
>
> IMO the protocol is not useful with a max payload of 1 IP packet.
>
> The YANG Patch overhead alone can take up 100s of bytes.
>
> Expect that a server will reject a configuration attempting to set this
> parameter to false.
>
>
>
> 3) Overflow indication
>
> There is no way for the server to indicate that the push update is
> truncated
>
> and should be discarded. A streaming server may not know how many segments
>
> are left for the current push update.
>
>
>
> 4) Application Layer
>
> NETCONF already has an application layer and application message framing.
>
> The UDP "application' is not clearly defined. It seems to just be "the
>
> notification message from NETCONF".
>
>
>
> 5) Implementation details
>
> For client/server tools that already support notifications, there
>
> is very little code reuse possible.  Code that uses the base:1.0 or
>
> base:1.1 message framing cannot rely at all on the transport protocol
>
> for proper framing.
>
>
>
> We are looking at using the NETCONF base:1.1 encoding with enhancements.
>
> The "NETCONF stream" encoding solves every problem mentioned above,
>
> except overflow indication, because that can never happen.
>
>
>
> Andy
>
>
>
>
>
>
>
> ReplyForward
>
>
>